W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: What are "appropriate Cache-Control or Expires header fields"

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 29 Dec 2009 20:23:21 +1100
Cc: Brian Smith <brian@briansmith.org>
Message-Id: <B68316AC-A213-4973-BEB8-E7BC49004151@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:14 GMT