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

[Mark Nottingham <[e-mail]>]

On 18/02/2013, at 1:44 PM, Amos Jeffries <[e-mail]> 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.

Cheers,


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