W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: i37 - Vary and non-existant headers

From: Adrien de Croy <adrien@qbik.com>
Date: Wed, 14 Nov 2007 19:10:47 +1300
Message-ID: <473A9167.9060301@qbik.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: 'HTTP Working Group' <ietf-http-wg@w3.org>



Adrien de Croy wrote:
>
> Bjoern Hoehrmann wrote:
>> * Adrien de Croy wrote:
>>   
> Some capabilities may have been inserted in previous requests by a 
> proxy in the chain, which may not be in the chain for this request.  
> e.g. Accept-Encoding: gzip inserted by a proxy trying to save upstream 
> bandwidth intending to expand it before sending it to the client which 
> doesn't support gzip itself.
This lead me to an interesting discussion on ETags and Variants.

Until about 25 minutes ago, I was a proponent of different encodings of 
the same resource being treated as the same resource, due to the fact 
that the encoding should be lossless.  However, this I now believe is 
impossible.  The reason I haven't seen discussed, so thought I'd toss it 
out there.

Servers don't want the overhead of compressing a file every time someone 
requests it compressed, vs serving it straight when not.  So, the server 
maintains a cache of pre-compressed versions of the file. Or a server 
may use a downstream accelerator to do this.

It's impossible to guarantee that changes in the original document can 
be made and propagated in step with the (possibly cached) compressed 
version.  Therefore there will be windows in time where the compressed 
version does not reflect the current version of the file.  It's possible 
even the resource could change whilst the server is updating the 
compressed version.  Therefore all encodings must be treated as a 
separate entities with their own ETag (unless the server takes the hit 
of on-the-fly compression).  Whilst a server could feasibly take 
(brutal) steps to guarantee synchronisation and use the same ETags, it 
can't guarantee that a downstream cache would.

This makes it (very unfortunately) a bad idea for a proxy to decide to 
try and save bandwith by inserting an Accept-Encoding: gzip header as 
mentioned above, since that invalidates the ETag that the client may 
have provided.  I guess that's why the spec says proxies must not touch 
end-to-end headers. 


 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 14 November 2007 06:10:08 GMT

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