- From: Adrien de Croy <adrien@qbik.com>
- Date: Fri, 08 May 2009 13:06:44 +1200
- To: Brian Smith <brian@briansmith.org>
- CC: 'HTTP Working Group' <ietf-http-wg@w3.org>
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