Re: ETags vs Variants, was: Revising RFC2616 - what's happening

On Oct 20, 2006, at 11:46 AM, Julian Reschke wrote:

> Roy T. Fielding schrieb:
>> On Oct 20, 2006, at 11:27 AM, Julian Reschke wrote:
>>> Well, that's clearer, but not my interpretation of what it should  
>>> say. Don't we want a missing header to be treated the same way as  
>>> an empty header?
>> Nope.  They usually don't mean the same thing (see Accept).
>>> That is, if the cache has a cached response from a previous  
>>> request with "Accept-Language: de", and the server replied with  
>>> "Vary: Accept-Language", can a subsequent request without "Accept- 
>>> Language" header be served with the cached reply? I wouldn't have  
>>> thought so....
>> No, we have no idea what the language pref algorithm is on the  
>> server.
>
> Right. So we don't want the cache to serve the cached response in  
> absence of the request header, right?
>
> But if we say (as you suggested):
>
> "When the cache receives a subsequent request whose Request-URI  
> specifies one or more cache entries including a Vary header field,  
> the cache MUST NOT use such a cache entry to construct a response  
> to the new request unless the set of selecting request-headers  
> present in the new request match the corresponding set of stored  
> request-headers in the original request."
>
> In this case, the cache would have an entry where the set of stored  
> request headers is "Accept-Language", which isn't present in the  
> new request. Thus, the cache would be allowed to use the cached  
> entry, right (because the set of selecting response headers  
> *present* in the request is empty).

Oh, that is not how I was interpreting "present" (the set is present,  
not
the set of present header fields).  It is actually unambiguous, but  
only if
you parse the sentence carefully.  Delete "present" if you like.

The empty set {} != {"Accept-Language: de"}, and therefore the cached
response will not be used.

....Roy

Received on Friday, 20 October 2006 19:05:06 UTC