Heuristics and "negative caching"

Right now, p6 defines the list of response status codes that can be heuristically cached as:

  200, 203, 206, 300, 301 and 410

in <http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-14#section->.

This was rather torturously extracted from this text in 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4>:

A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching. However, a cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial Content) responses.

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. For example, these include the following: an Expires header (section 14.21); a "max-age", "s-maxage", "must- revalidate", "proxy-revalidate", "public" or "private" cache-control directive (section 14.9).

However, I think that this list is too constraining; implementations commonly apply a heuristic to other status codes, both for performance reasons and to avoid load on the origin server. 

For example, Squid allows "negative caching" -- effectively a heuristic -- on the following response status codes:
  204, 400, 401, 404, 405, 414, 500, 501, 502, 503, 504
See <http://www.squid-cache.org/Doc/config/negative_ttl/> for details.

If you squint at the new Chrome throttling feature <http://dev.chromium.org/throttling>, I think it can be viewed as a heuristic on errors as well.

Minimally, I think we should allow heuristic caching on 404s, as this is very common practice, since they so often don't have explicit freshness information. 

I think we should also consider 204 and 400.

The 5xx codes probably need some discussion if we want to add them, as they indicate a (usually) transient server-side error.


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

Received on Thursday, 28 April 2011 06:14:14 UTC