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

Adrien de Croy wrote:
> Brian Smith wrote:
> > Adrien de Croy wrote:
> >> 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.
> >
> right, hence my comment maybe Vary should be a MUST.  But I'm sure
> there would be a multitude of problems if that happened.
> 
>  So I guess if there's no Vary, what do we we fall back to?

A cached response can always be returned unless its Vary header says it
can't be. If some responses included a Vary header and then a later
cacheable response doesn't include one (for the same resource), then the
later response will effectively replace all the other cached responses
because of the "most recent" rule.

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

> The basis I've been working on is that the method should be part of the
> key as long as it's not GET or HEAD, since otherwise you couldn't reply
> to a HEAD with the cached results of a previous GET as you'd get an
> index miss.
> 
> In that case there's no ambiguity about the other methods, so we'd be
> back to arguably needlessly invalidating valid stored representations.

It seems you are suggesting that it would be better if there was some way
for a POST request to indicate that no invalidation is necessary. I agree.
However, the Cache-Control of the POST response cannot be overloaded for
that purpose. Some other (new) mechanism would be needed, which would be out
of scope of the HTTPbis effort.

> > Content-Location is only used by caches for invalidation, and never
> > for any other reason (by caches). Basically, when choosing which cache
> > entries to invalidate, you must invalidate all the ones with the same
> > Content-Location, subject to the "same-origin" restriction explained
> > above.
> 
> If a shared cache however appends a bunch of ETags to an If-None-Match
> header, then the server selects from those using Content-Location, then
> the shared cache / proxy needs to return the resultant selected entity?
> Same as if the origin server returned an ETag.

I'm not sure what you mean here. The origin server doesn't use
Content-Location to choose a variant; it is going to use the request to
choose a variant. 

- Brian

Received on Wednesday, 27 May 2009 05:04:49 UTC