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: Henrik Nordström <henrik@henriknordstrom.net>
Date: Fri, 14 May 2010 11:02:04 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Brian Smith <brian@briansmith.org>
Message-Id: <1273827724.7134.29.camel@localhost.localdomain>
ons 2010-03-03 klockan 16:47 +1100 skrev Mark Nottingham:
> I haven't heard any more feedback about this. AFAICT the only thing remaining in this issue <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/199> is to adjust the language in p2-semantics that originally brought this up.
> 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.

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

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.

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.

Received on Friday, 14 May 2010 09:02:39 UTC

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