W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 18 Feb 2013 14:53:15 +1100
Cc: ietf-http-wg@w3.org
Message-Id: <7471217E-D88B-47B4-93E7-C06DA1E78EE2@mnot.net>
To: Amos Jeffries <squid3@treenet.co.nz>

On 18/02/2013, at 1:44 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> 	 502 (Bad Gateway)
>> 	 503 (Service Unavailable)
>> 	 504 (Gateway Timeout)
> These ones are often temporary conditions and where we have the most trouble with Squid despite the automatic re-try of alternative routes. A short glitch in DNS or routing can trigger them and DoS the caches entire client base for an overly-large timespan. It often does make sense to cache them, but only for very short time (seconds at most) and not in caches outside of the device which generated them.
> For devices with only one upstream route; the upstream outage is a problem for as long as the upstream sets cacheability on the reply.
> For devices with multiple upstream routes; the alternative routes may have shorter recovery times (mandatory decrease in cached time?) or be fully working for this request.
> Either way I am against caching these set without explicit Expiry information being present.

I'm fine with that; was nervous about including them on that list in the first place.

> Note that I'm *not* proposing the following, even though they are negatively cached by some implementations, as I suspect doing so may cause interop problems:
>> 	 400 (Bad Request)
>> 	 403 (Forbidden)
>> 	 500 (Internal Server Error)
>> Thoughts?
> 403 Forbidden might be cacheable when a Vary:WWW-Authenticate is also in the reply

Sure, but if you set Vary, you can also set CC; this isn't a common use, and lots of people use 403 to mean "forbidden for ill-defined reasons", so using a heuristic would likely get them in trouble.


Mark Nottingham   http://www.mnot.net/
Received on Monday, 18 February 2013 03:53:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC