- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 20 Nov 2009 11:25:45 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Brian Smith <brian@briansmith.org>
[ sorry, I thought I sent this out quite some time ago. ] I've been thinking about this more, and trying to make the spec changes. I'm now at a place where it looks like the most minimal thing we can do to clarify this (vs. 2616) is: - unknown / unimplemented status codes are not cacheable (e.g., 206 when appropriate) - responses that have explicit freshness are cacheable - status codes that explicitly allow heuristic freshness are cacheable Otherwise, we're going to have to make a determination regarding the cacheability of every status code, and some of them are going to be difficult. It's true that going in the direction outlined above will allow people to assign cacheability to things where it doesn't make sense, but I'd argue that a) this isn't a real interop problem now, and b) if this is the case, what we should do is raise a separate issue (e.g., "404 responses should not be cacheable"), so that we can be sure we don't break current implementations. On 03/11/2009, at 1:39 PM, Mark Nottingham wrote: > Roy pointed out in conversation that 206 is most relevant here; it changes the interpretation of a response fundamentally. I.e., it's legitimate for a 206 to have directives that make it cacheable, but if a cache doesn't understand the 206 status code, it can't be cached. > > As such, it seems like there's already a precedent; a cache has to understand the status code, as Brian points out. > > So, it looks like (c)... > > I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/199> to track this. Unless I see any disagreement, I'll start incorporating (c) into the next draft. > > > > On 22/10/2009, at 4:30 PM, Mark Nottingham wrote: > >> >> On 23/10/2009, at 2:20 AM, Brian Smith wrote: >> >>> If it doesn't make sense to cache a response, then the origin server >>> shouldn't be including the Cache-Control/Expires headers in its response. I >>> think that's your position and I totally agree with that. >> >> Yes. >> >>> But, it seems >>> strange to me to say a cache may cache anything with a Cache-Control header >>> as-is--EXCEPT it must treat 201, 206, 304, 417 (and probably a few more >>> 4xx/5xx errors) specially, but that's it, no new special cases, ever. >> >> >> Right. If we follow this path, there are roughly three options; >> >> a) Make exceptions for 201, etc. and no more >> b) Don't make exceptions for 201, etc. -- i.e., purposefully allow servers to shoot themselves in the foot here (without promoting it, of course) >> c) Allow new status codes to except them, which takes us back to caches having to understand status codes to store them. >> >> If we were working from a clean slate, I think (b) is probably the right thing to do. However, we're not -- although adopting (b) won't make any existing caches non-conformant: one could argue that a 201 or a 281 w/ Expires can be cached, thanks to the advice that Expires makes a non-cacheable response cacheable. >> >> How do people feel about this? Is (b) workable? If not, (a) or (c), or something else? >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/
Received on Friday, 20 November 2009 00:26:26 UTC