- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 18 Feb 2013 14:53:15 +1100
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
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. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 18 February 2013 03:53:42 UTC