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

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 <>  
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

Mark Nottingham

Received on Tuesday, 3 November 2009 21:40:07 UTC