-
Couldn't load subscription status.
- Fork 79
Description
Per:
guzzle-cache-middleware/src/Strategy/PrivateCacheStrategy.php
Lines 33 to 45 in e1430d9
| protected $statusAccepted = [ | |
| 200 => 200, | |
| 203 => 203, | |
| 204 => 204, | |
| 300 => 300, | |
| 301 => 301, | |
| 404 => 404, | |
| 405 => 405, | |
| 410 => 410, | |
| 414 => 414, | |
| 418 => 418, | |
| 501 => 501, | |
| ]; |
and:
guzzle-cache-middleware/src/Strategy/PrivateCacheStrategy.php
Lines 66 to 69 in e1430d9
| if (!isset($this->statusAccepted[$response->getStatusCode()])) { | |
| // Don't cache it | |
| return; | |
| } |
...the caching middleware does not cache a 201 response. I believe this is not compliant with the RFC on caching, and should in fact be cached if the response contains the appropriate caching headers.
https://tools.ietf.org/html/rfc7231#section-6.1 states that:
Responses with status codes that are defined as cacheable by default
(e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
this specification) can be reused by a cache with heuristic
expiration unless otherwise indicated by the method definition or
explicit cache controls [RFC7234]; all other status codes are not
cacheable by default.
If I am reading this correctly, that does not mean that status codes in this list must not be cached, but that they must not be cached by default. A status code not in this list (e.g. 201) is still cacheable if there are appropriate Cache-Control headers, as indicated in https://tools.ietf.org/html/rfc7234#section-3:
A cache MUST NOT store a response to any request, unless:
...
the response either:
...
- contains a Cache Control Extension (see Section 5.2.3) that allows it to be cached, or
In my particular case, I am receiving a 201 with a header of Cache-Control: public, max-age=60, s-maxage=60, and expect it to be cached.