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

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