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

On 18/02/2013 1:12 p.m., Mark Nottingham wrote:
> I haven't seen any discussion, and this is our last ticket (at least for the moment).

Sorry I didn't get to reply to this earlier...


You pointed at Squid as a widely used implementation doing negative 
caching. I would like to point out it in its current form it has been no 
end of trouble and we are actively advising people disable it. The 
usefulness seems to be greatest for reverse-proxy installations where 
the backend generation of errors is much more under control of the proxy 
admin. In general proxy installations it already commonly leads to the 
DoS vulnerability mentioned in the earlier thread.

For now Squid only caches these if it generated the response itself 
(with a short TTL) or if the appropriate caching controls are present 
AND the admin explicitly enabled a negative caching timeout limiting the 
storage.


>
> So, I'll make a proposal; we should identify the following additional status codes as cacheable (i.e., eligible for using a heuristic to determine freshness, in the absence of explicit information);
>
> 	• 204 (No Content)

+1.  200 is cacheable, therefor all 2xx SHOULD be cacheable or at least 
harmless when cached.

> 	• 404 (Not Found)
> 	• 405 (Method Not Allowed)
> 	• 414 (Request URI Too Long)
> 	• 501 (Not Implemented)

+1. These ones make a lot of sense due to the long-term nature of the 
problems they are reporting. Even heuristic caching would seem to be safe.


> 	• 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.


> 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

400 and 500, I agree should be left non-cacheable by default so that 
their future 4xx/5xx sub-codes are not affected.

/2c
Amos

Received on Monday, 18 February 2013 02:44:32 UTC