Which status codes are cacheable?

[Brian Smith-19]

In Part 2, the definitions of 300, 301, 302, 303, 307, and 410 status codes
explicitly state that they are cacheable. However, none of the other status
codes state explicitly whether or not they are cacheable.

Part 6, Section 2.1 (Response Cacheability) doesn't give any restrictions on
storing a response a response based on its status code. By the way it is
written, implicitly a response with any status code may be cached.

I believe Part 6, Section 2.1 needs to be changed to add an extra
requirement analogous to the requirement for method cacheability:

    ...
    * The request method is defined as being cacheable, and
+   * The response is cacheable according to the definition
+      of the response's status code, and
    ...

Explicit statements in each cacheable status code's definition would need to
be added as well.

The following are always cacheable: 200, 203, 204, 205, 300, 301, 410.

I think the following should be cacheable only when an appropriate Expires
or Cache-Control are present: 302, 303, 307, 401, 403, 404, 405, 406, 500,
501, 502, 503, 504, 505.

I am not sure about the other status codes, but I believe that the following
should probably never be cached: 201, 202, 305, 306, 402, 408, 409, 411,
412, 413, 415, 417.

Regards,
Brian

[mnot]

On 13/10/2009, at 12:15 PM, Brian Smith wrote:

> In Part 2, the definitions of 300, 301, 302, 303, 307, and 410  
> status codes
> explicitly state that they are cacheable. However, none of the other  
> status
> codes state explicitly whether or not they are cacheable.
>
> Part 6, Section 2.1 (Response Cacheability) doesn't give any  
> restrictions on
> storing a response a response based on its status code. By the way  
> it is
> written, implicitly a response with any status code may be cached.

Yes. The corresponding part of 2616 is 13.4, Response Cacheability,  
which isn't crystal-clear, but does lean heavily towards the view that  
status codes do NOT affect what is storeable. See below.

> I believe Part 6, Section 2.1 needs to be changed to add an extra
> requirement analogous to the requirement for method cacheability:
>
>    ...
>    * The request method is defined as being cacheable, and
> +   * The response is cacheable according to the definition
> +      of the response's status code, and
>    ...
>
> Explicit statements in each cacheable status code's definition would  
> need to
> be added as well.
>
> The following are always cacheable: 200, 203, 204, 205, 300, 301, 410.
>
> I think the following should be cacheable only when an appropriate  
> Expires
> or Cache-Control are present: 302, 303, 307, 401, 403, 404, 405,  
> 406, 500,
> 501, 502, 503, 504, 505.

Putting aside the editorial issues of how the spec is structured, I  
think the core of your issue is that you'd like to see status codes  
not only affect what can be served with heuristic freshness (which is  
quite clearly specified in 2616), but also affect:
   1) what can be served from cache under unusual circumstances, such  
as when the origin server can't be contacted (which is allowed by  
2616's 13.1.1 and 13.1.5), and
   2) what can be served from cache with client-specified freshness  
(using max-age and max-stale request CC). This is covered in 2616's  
13.1.6; a client can relax semantic transparency using max-stale.  
Interestingly, 13.4 doesn't specified that other status codes being  
served is dependent upon *response* cache-control being present, only  
cache-control.

Restricting what gets stored is one way to do that, of course, but  
either way it's done, the effect is the same.

My reading is that while it's not crystal-clear, 2616 doesn't  
predicate whether a response can be stored upon its status code, because
   a) no where is this specified with a MUST or SHOULD-level  
requirement, and
   b) caches are explicitly allowed (with a MAY) to store any  
successful (in the sense of "it's complete") response, and
   c) cache-control headers are explicitly allowed to relax semantic  
transparancy for any response -- including those with unknown status  
codes.

However, I agree that it's not at all clear which of the following  
2616 requirements takes precedence:

>  A response received with any other status code (e.g. status codes 302
>    and 307) MUST NOT be returned in a reply to a subsequent request
>    unless there are cache-control directives or another header(s) that
>    explicitly allow it.

and

>         If a stored response is not "fresh enough" by the most
>          restrictive freshness requirement of both the client and the
>          origin server, in carefully considered circumstances the  
> cache
>          MAY still return the response with the appropriate Warning
>          header (see section 13.1.5 and 14.46), unless such a response
>          is prohibited (e.g., by a "no-store" cache-directive, or by a
>          "no-cache" cache-request-directive; see section 14.9).


I don't have very strong feelings here, although would note that  
returning a stale 302 or 307 when disconnected from the origin server  
seems like a reasonable use case, on the face of it. Anyone else?

I'll also try to test a few implementations to see if anyone is  
actually returning a stale 302 (for example) when disconnected.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

[Brian Smith-19]

Mark Nottingham wrote:

> My reading is that while it's not crystal-clear, 2616 doesn't
> predicate whether a response can be stored upon its status code,
> because
>    a) no where is this specified with a MUST or SHOULD-level
> requirement, and
>    b) caches are explicitly allowed (with a MAY) to store any
> successful (in the sense of "it's complete") response, and
>    c) cache-control headers are explicitly allowed to relax semantic
> transparancy for any response -- including those with unknown status
> codes.

This is not true. See RFC2616, Section 6.1.1:

  However, applications MUST understand the class of any status code,
  as indicated by the first digit, and treat any unrecognized
  response as being equivalent to the x00 status code of that class,
  with the exception that an unrecognized response MUST NOT be cached.

This same restriction is also in Part 2, Section 4 of the latest draft,
RFC2068 Section 6.1.1, and RFC1945 Section 6.1.1.

Regards,
Brian