W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: i37: Vary and non-existant headers

From: Adrien de Croy <adrien@qbik.com>
Date: Fri, 08 May 2009 10:57:21 +1200
Message-ID: <4A036751.5070303@qbik.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Brian Smith <brian@briansmith.org>, 'Mark Nottingham' <mnot@mnot.net>, 'HTTP Working Group' <ietf-http-wg@w3.org>

In the case of say Accept-Encoding, what if a server sends a vary tag 
with Accept-Encoding in it, yet there is no Content-Encoding field (e.g. 
no encoding, but the server selected on Accept-Encoding)?

It would then seem pointless for a cache to refuse to send an unencoded 
response (that would otherwise be valid) simply because a subsequent 
request didn't state it would be willing to accept an encoding.

Or is that second-guessing the server and prohibited?


Julian Reschke wrote:
> 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
>
>
>
>
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Thursday, 7 May 2009 22:54:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:02 GMT