- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 29 Dec 2009 20:23:21 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Brian Smith <brian@briansmith.org>
Making some progress here: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/737 On 20/11/2009, at 11:25 AM, Mark Nottingham wrote: > [ 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/ > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 29 December 2009 09:23:54 UTC