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

From: Henrik Nordström <[email-masked]>
Date: Fri, 14 May 2010 10:37:02 +0200

ons 2009-11-11 klockan 16:31 -0300 skrev Nicolas Alvarez:

> Quote RFC3229 section 5.5:

Would be interesting to know what scenario this refers to:

   Warning to origin server implementors: it does not suffice to send

      Vary: If-None-Match, A-IM

   in status-226 responses.  We have discovered at least one scenario
   where this does not prevent a proxy cache that does not implement IM
   and A-IM from incorrectly "validating" a cached 226 response.

A guess is that this is related to their idea that using Expires is not
a good method for telling HTTP/1.0 caches that this response is
incompatible with HTTP/1.0 cache rules even when HTTP/1.1 clearly states
that using Expires is the preferred method for indicating this to any
HTTP/1.0 implementations along the response path.

Any RFC3229 Delta Encoding in HTTP authors around on this list that care
to comment?

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 14 May 2010 11:02:04 +0200

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

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.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 May 2010 11:52:32 +1000

> response. Caches not understanding 206 or 304 MUST NOT cache them.

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

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

> not have that response cached.

What are you suggesting here?

Regards,

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