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 18:24:15 +1300
Message-ID: <473A867F.4090501@qbik.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: 'HTTP Working Group' <ietf-http-wg@w3.org>



Bjoern Hoehrmann wrote:
> * Adrien de Croy wrote:
>   
>> However for Accept-Encoding, I believe this is an advertisement of 
>> capability by the client, and absence of this advertisement should be 
>> taken to mean the capability isn't there, and therefore this is a 
>> non-match. (PS, this is another instance of where a reference to the 
>> "identity" coding should be removed).  There is also explicit wording 
>> for how to deal with a missing header in this case also which disagrees 
>> with me - states that "the server MAY assume that the client will accept 
>> any content coding".  This however IMO is dangerous, and the SHOULD 
>> requirement to send "identity" should be replaced by MUST send 
>> unencoded.  Otherwise we are making gzip, deflate etc all mandatory.
>>     
>
> I am not sure what you are suggesting here. The requirement is a poorly
> phrased "SHOULD unless" one, do you want to change this into "MUST un-
> less" or into simply "MUST"? I don't think the latter is appropriate
> (if I know for some reason the client can handle the response, there is
> nothing wrong with sending an encoded entity body), and turning it into
> a "MUST unless" is not meaningful, since "SHOULD" is already "MUST un-
> less".
>   

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?

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.

IMO if the client doesn't advertise a capability for a request, it 
should not be assumed to be available for that request, regardless of 
any previous requests that may have advertised a capability. Therefore 
to act as if an optional capability is available when not expliocitly 
advertised is dangerous. 

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 14 November 2007 05:23:40 GMT

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