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

On 14/05/2010, at 7:02 PM, Henrik Nordström wrote:

> ons 2010-03-03 klockan 16:47 +1100 skrev Mark Nottingham:
>> 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
> 
> I'd recommend to keep a note in 206 & 304, mentioning that these can
> only be cached as if they are a partial representation of a 200
> response. Caches not understanding 206 or 304 MUST NOT cache them.

I don't see any harm in reinforcing that point.


> As for the other status codes, expiry information (expires, max-age etc)
> == cachable. A server sending expiry information on a response which it
> does not intend to be cached is welcome to shoot itself in the foot. No
> expiry information == heuristics if explicitly allowed otherwise
> uncachable.
> 
> Protocol extensions adding new status codes which changes the
> interpretation of the response body need to think carefully, and make
> sure appropriate Vary header is returned.

That's the original position I took, but Roy convinced me that this wasn't workable. If someone wants to introduce another status code that's a partial representation (e.g., 226), Vary won't help them; hence the requirement that a cache understand a status code before storing it. Also, as Brian pointed out, 2616 already states that unrecognised status codes MUST NOT be cached.


> Regarding storage, it's not the specifications job to define how caches
> store responses, only how they react on subsequent requests when using
> those earlier responses as input for satisfying the current request.
> Only exception here is the no-store directive. The rules on invalidation
> is at large separate from storage, with just one exception where a
> certain cache invalidation requires the cache to then act as if it does
> not have that response cached.


What are you suggesting here?

Regards,

--
Mark Nottingham     http://www.mnot.net/

Received on Monday, 24 May 2010 01:53:05 UTC