- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 28 Apr 2011 16:13:46 +1000
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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-2.3.1.1>. 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. Thoughts? -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 28 April 2011 06:14:14 UTC