Re: draft-ietf-httpbis-p6-cache-06

Brian Smith wrote:
> Adrien de Croy wrote:
> > This leaves problems if there's no Vary header but content negotiation
> > was used.  It's not possible to reliably heuristically determine if
> > content-negotiation was used without the Vary header.  Vary is only a
> > SHOULD level.  Maybe it should be a MUST level?
> 
> As you noted below, this rule applies:
> 
>    Caches MUST use the most recent response (as determined by the Date
>    header) when more than one suitable response is stored.  They can
>    also forward a request with "Cache-Control: max-age=0" or "Cache-
>    Control: no-cache" to disambiguate which response to use.
> 
> Using this rule, along with other rules for caches, results in predictable
> behavior, right?

Requests with "Cache-Control: no-cache" bypass the cache, and do _not_
always result in the most recent response (as determined by the Date
header) being forwarded.  They require the exact corresponding
response to be forwarded.  Think about overlapping concurrent requests
and responses in various orders, various times to forward parts of
each message and generate the response, and with various Date values.


> > There needs to be another set of checks, at the minimum that
> > Accept-Encoding matches the stored Content-Encoding.  E.g. you
> > can't serve gzip content if there's no Accept-Encoding: gzip.
> > Arguably others as well (like Accept-Language
> > matching on Content-Language , with q values etc).
> 
> Actually, a server *is* allowed to do that. And, caches don't have to worry
> about that because they don't have to interpret Accept-* and Content-*
> headers. (See my previous message in the other thread.)

I agree.  A server can serve whatever it likes, and cache is not
supposed to interpret those headers itself.

> > It says if there are several stored representations serve the one with
> > the most recent Date header (MUST level), but this may not be the
> > appropriate one if Vary headers aren't available, and you are say
> > selecting based on language.
> 
> The server needs to provide a Vary header in that case.

I agree.  Selecting based on language is a server decision - the cache
does not know what policy the server uses to decide the language of
responses.

> > Wrt POST (or any method).  If the response to a POST is marked
> > explicitly by the origin server as cachable, why should a subsequent
> > POST invalidate that contrary to other Cache-control directives?
> > Surely this should only apply if the original method was not POST?
> 
> See the discussion about whether the method is part of the cache key. Caches
> really need to be very conservative here (that is, MUST invalid) as there
> seems to be a lot of disagreement amongst implementers and standardistas
> regarding this issue.

Conservative is good, but not too conservative that anything with
Vary, varying Vary, or '?' in the URL is uncacheable, as some caches
implement :-)

-- Jamie

Received on Sunday, 7 June 2009 23:29:09 UTC