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:29:18 +1300
Message-ID: <473A95BE.5030409@qbik.com>
To: 'HTTP Working Group' <ietf-http-wg@w3.org>



Bjoern Hoehrmann wrote:
> * Adrien de Croy wrote:
>   
>> How can you know for sure that a client has a capability when the client 
>> doesn't advertise it in that particular request?  How can the 
>> server/proxy/cache even know it's the same client, or going through the 
>> same request chain?  (e.g. load-balancing through a heterogenous proxy 
>> farm) If it's from a previous request advertising some capability, why 
>> would a sane client arbitrarily (?) decide to cease advertising that 
>> capability if in fact it's still available?
>>     
>
> Well I was really asking what change you would like to see. There are
> three paragraphs dealing with the lack of Accept-Encoding, are you pro-
> posing to replace all of them by saying, if you can send it without any
> encoding, then you must send it without any encoding if A-E is missing?
> Or would you go even further and prohibit sending an encoded body even
> if the server cannot send an unencoded body (you'd send 406 instead)?
>   
OK.

Just basically that since the encodings are optional, and you can't
guarantee a client can use any content other than unencoded, then the
only safe option where there is no C-E header is to send unencoded or
406 if you don't have an unencoded one (when will that ever happen on an
origin server?).

I guess it's all very well in custom applications for a server to know a
particular client say has a particular capability without that client
explicitly advertising it (e.g. some media apps), but this isn't
something we could expect an intermediary caching proxy to be aware of.
Those clients should still advertise the capability.  A 406 certainly
would prompt UA developers to start advertising capabilities.

Actually if there is no unencoded content, then you should be able to
deem the content to be unencoded.  E.g if a certain resource is only
ever available as gzipped, and clients only ever get it as gzipped, then
Content-Encoding: gzip shouldn't be used (the gzipped version is the
"identity"), since that entices intermediaries to try and unzip it and
send unzipped versions.

Or do you know of other use cases I'm missing?

Regards

Adrien

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

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