- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 27 May 2009 00:04:10 -0500
- To: "'Adrien de Croy'" <adrien@qbik.com>
- Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
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