Re: i37: Vary and non-existant headers

Brian Smith wrote:
> Adrien de Croy wrote:
>   
>> 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)?
>>     
>
> That is the normal case. If the server decided to send a non-encoded version
> due to the absence of an Accept-Encoding, then it has to include
> Accept-Encoding in the Vary. 
>
>   
that's not what I meant.  I meant maybe the original request had an 
Accept-Encoding header, the server sent back a response with Vary 
Accept-Encoding, but no Content-Encoding header, since it wasn't 
encoded.  this was then cached.

Then another request came in without an Accept-Encoding header.

What I'm trying to get at is: is there any case to be made for 
validation between the Accept-* headers and the matching Content-* 
headers of the original request and response, and whether this should 
have any bearing on matching for subsequent requests.

Regards

Adrien

>> Or is that second-guessing the server and prohibited?
>>     
>
> Yes, the cache must return what the server told it to return:
>
>    If instead the cache receives a full response (i.e., one with a
>    response body), it is used to satisfy the request and replace the
>    stored response. [[anchor8: Should there be a requirement here?]]
>
> and:
>
>    If the server responds with 304 (Not
>    Modified) and includes an entity tag or Content-Location that
>    indicates the entity to be used, that cached response MUST be used
>    to satisfy the presented request [...]
>
> - Brian
>
>   

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

Received on Friday, 8 May 2009 01:04:12 UTC