As stated in the title, which HTTP status codes are acceptable to cache as a browser? I did a quick search and did not find an authoritative answer.
Originally I thought it may only be 200
OK responses, but I couldn't find any evidence to support that thought.
"Responses to POST method are not cacheable, UNLESS the response includes appropriate Cache-Control or Expires header fields." So, YES, you can cache POST request response but only if it arrives with appropriate headers. In most cases you don't want to cache the response.
Caching in REST APIs POST requests are not cacheable by default but can be made cacheable if either an Expires header or a Cache-Control header with a directive, to explicitly allows caching, is added to the response. Responses to PUT and DELETE requests are not cacheable at all.
Both of these suggest that 'no', PATCH is not cacheable, and there's no set of HTTP headers that will make it so.
Caching refers to storing the server response in the client itself, so that a client need not make a server request for the same resource again and again.
According to the RFC 7231, the current reference for content and semantics of the HTTP/1.1 protocol, the following HTTP status codes are defined as cacheable unless otherwise indicated by the method definition or explicit cache controls:
200
OK203
Non-Authoritative Information204
No Content206
Partial Content300
Multiple Choices301
Moved Permanently404
Not Found405
Method Not Allowed410
Gone414
URI Too Long501
Not ImplementedThe RFC 7231 states the following regarding the HTTP status codes that are cacheable by default:
6.1. Overview of Status Codes
[...] Responses with status codes that are defined as cacheable by default (e.g.,
200
,203
,204
,206
,300
,301
,404
,405
,410
,414
, and501
in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls; all other status codes are not cacheable by default. [...]
Once the HTTP status codes are extensible, recipient must note cache a response with an unrecognized status code:
6. Response Status Codes
The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.
HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the
x00
status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code. [...]
The cache also depends on the HTTP method:
4.2.3. Cacheable Methods
Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines
GET
,HEAD
, andPOST
as cacheable, although the overwhelming majority of cache implementations only supportGET
andHEAD
.
Regarding the POST
method, there's an important detail:
4.3.3. POST
[...] Responses to
POST
requests are only cacheable when they include explicit freshness information [...]
For more details, check the definition of each method.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With