Fwd: [httpbis] #432: Review Cachability of Status Codes WRT "Negative Caching"

... and this is the ticked I just promised:

Begin forwarded message:

> From: "httpbis" <trac+httpbis@trac.tools.ietf.org>
> Subject: [httpbis] #432: Review Cachability of Status Codes WRT "Negative Caching"
> Date: 11 February 2013 5:27:44 PM AEDT
> To: mnot@pobox.com
> Reply-To: ietf-http-wg@w3.org
> 
> #432: Review Cachability of Status Codes WRT "Negative Caching"
> ----------------------------+-----------------------------
> Reporter:  mnot@pobox.com  |      Owner:
>     Type:  design          |     Status:  new
> Priority:  normal          |  Milestone:  unassigned
> Component:  p6-cache        |   Severity:  In WG Last Call
> Keywords:                  |     Origin:  #223
> ----------------------------+-----------------------------
> Currently, the following status codes are defined as cacheable -- that is,
> able to be stored without any explicit freshness information:
> 
> - 200 (OK)
> - 203 (Non-Authoritative Information)
> - 206 (Partial Content)
> - 300 (Multiple Choices)
> - 301 (Moved Permanently)
> - 410 (Gone)
> 
> However, many caches store other status codes (often called "Negative
> Caching")
> 
> For example, both Squid and Traffic Server (which have considerable market
> share, and form the basis of many other implementations) negatively cache
> the following status codes:
> 
> - 204 (No Content)
> - 400 (Bad Request)
> - 403 (Forbidden)
> - 404 (Not Found)
> - 405 (Method Not Allowed)
> - 414 (Request URI Too Long)
> - 500 (Internal Server Error)
> - 501 (Not Implemented)
> - 502 (Bad Gateway)
> - 503 (Service Unavailable)
> - 504 (Gateway Timeout)
> 
> While some of these may be bad to cache by default (in particular, 400 and
> 500), others may make sense: for example, 204 seems straightforward, and
> 404 seems high-value.
> 
> The major concern here is making semantic changes to the protocol.
> 
> -- 
> Ticket URL: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/432>
> httpbis <http://tools.ietf.org/wg/httpbis/>
> 

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

Received on Monday, 11 February 2013 06:29:55 UTC