W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Heuristics and "negative caching"

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 28 Apr 2011 16:13:46 +1000
Message-Id: <A81C1E74-1F99-4F0E-B8CC-97EDF8CC44F7@mnot.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:40 GMT