W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

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

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 24 May 2010 11:52:32 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Brian Smith <brian@briansmith.org>
Message-Id: <D2515FBC-96F1-4B6B-AD4E-101B31893CC5@mnot.net>
To: Henrik Nordström <henrik@henriknordstrom.net>
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?


Mark Nottingham     http://www.mnot.net/
Received on Monday, 24 May 2010 01:53:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC