- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 3 Mar 2010 16:47:23 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Brian Smith <brian@briansmith.org>
I haven't heard any more feedback about this. AFAICT the only thing remaining in this issue <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/199> is to adjust the language in p2-semantics that originally brought this up. I think we should: 1) Remove all reference to caching from the status code definitions in p2 (e.g., most of the 3xx, 410), relying on it to be covered by p6, and 2) Move the text that associates heuristic freshness with individual status codes out of p6 into the appropriate status code definitions in p2, and 3) Allow future status codes to identify themselves as allowing heuristic freshness (the current requirement in p6 is IMO too strict of a reading of 2616, looking at it again). Thoughts? On 29/12/2009, at 8:23 PM, Mark Nottingham wrote: > 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/ > > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 3 March 2010 05:47:56 UTC