Re: i37: Vary and non-existant headers

Roy T. Fielding wrote:
> On May 7, 2009, at 12:43 PM, Julian Reschke wrote:
> 
>> Brian Smith wrote:
>>> Julian Reschke wrote:
>>>> "When a cache receives a request that can be satisfied by a stored
>>>> response that includes a Vary header field (Section 3.5), it MUST NOT
>>>> use that response unless all of the selecting request-headers nominated
>>>> by the *stored* Vary header match in both the original request
>>>> associated with the stored response, and the presented request."
>>> This is wrong, but not for the reason Jamie stated.
>>> Consider this:
>>> 1. Client requests "GET /foo"
>>> 2. Cache forwards the request to the server "GET /foo" with
>>>    an If-None-Match: "A", "B", "C"
>>> 3. Server returns "304 Not Modified" with ETag "A".
>>> According to the statement above, the cache could only return the cached
>>> response with ETag "A" if the Vary'd headers match; otherwise, it 
>>> couldn't
>>> return any response at all. However, the cache must be able to return 
>>> the
>>> response with ETag "A" regardless of whether the Vary'd headers match.
>>
>> Why?
>>
>> What you describe sounds like a bug. If the selecting headers that 
>> resulted in the response with entity tag "A" had a "Accept-Encoding: 
>> gzip", then the response can't be used for a request without 
>> "Accept-Encoding", even if it may be fresh.
> 
> Because the origin server just told the cache to deliver "A" in (3).
> The origin server is authoritative.
> 
> We've had this discussion before.

Right, sorry.

So the text is only needs to consider the case where the origin server 
gives its ok.

""When a cache receives a request that can be satisfied by a stored
response that includes a Vary header field (Section 3.5), it MUST NOT
use that response unless all of the selecting request-headers nominated
by the *stored* Vary header match in both the original request 
associated with the stored response, and the presented request, *or 
after validating with the origin server*".

?

BR, Julian