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

Brian Smith wrote:
> 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.
>
>   
I can see that a later one would always be served by the cache, however 
existing older ones could still be revalidated if say the client 
requested revalidation, or the freshest one expired.  Any time a 
revalidation is done, the cache could indicate all ETags for the URI.  
At that point, an older one could be selected by the origin server, 
which then would become the newest one for subsequent requests.

Seems to me this would lead to weird results, esp with multiple language 
versions of the same URI.

>>>> 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.
>
>   
so it's invalid to include a Cache-Control: public say on the POST response?


>>> 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. 
>   
It uses it to indicate a chosen variant is what I meant sorry.  the 
cache then uses the Content-Location field to choose from amongst a set 
of variants.

Adrien

> - Brian
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 27 May 2009 05:23:44 UTC