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: Fri, 23 Oct 2009 10:30:01 +1100
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <C66BBA28-89CB-46F0-B08A-5A495A99A29B@mnot.net>
To: Brian Smith <brian@briansmith.org>

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/
Received on Thursday, 22 October 2009 23:30:39 GMT

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