Which HTTP status codes are cacheable?

Question

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.

Answer 1

According to RFC7234 it is also allowed to cache responses that deliver another code than 200 (OK):

[...] The most common form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response to a GET request, which contains a representation of the resource identified by the request target (Section 4.3.1 of [RFC7231]). However, it is also possible to cache permanent redirects, negative results (e.g., 404 (Not Found)), incomplete results (e.g., 206 (Partial Content)), and responses to methods other than GET if the method's definition allows such caching and defines something suitable for use as a cache key.

So it's up to the browser developer what he wants to cache and what not.

Answer 2

Short answer

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 OK
• 203 Non-Authoritative Information
• 204 No Content
• 206 Partial Content
• 300 Multiple Choices
• 301 Moved Permanently
• 404 Not Found
• 405 Method Not Allowed
• 410 Gone
• 414 URI Too Long
• 501 Not Implemented

Long answer

The 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, 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; 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, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.

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.

Additional resources

• RFC 7234: Reference for caching in the HTTP/1.1 protocol
• Check what browsers store in their cache