W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: #285: Strength of requirements on Accept re: 406

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 22 Jun 2011 19:18:55 +1000
Cc: httpbis Group <ietf-http-wg@w3.org>
Message-Id: <CA779D31-F552-4276-BFBE-40B1118CB596@mnot.net>
To: Adrien de Croy <adrien@qbik.com>

On 22/06/2011, at 6:58 PM, Adrien de Croy wrote:

> 
> 
> On 22/06/2011 12:21 p.m., Mark Nottingham wrote:
>> Accept-Encoding has:
>> 
>> """
>> If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
>> 
>> If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header field, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
>> 
>> If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding.  In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
>> """
>> 
> 
> 
> "If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. "
> 
> This seems highly dangerous to me.  IMO it would be extremely foolhardy for a server to send back content gzipped when there was no Accept-Encoding header at all.
> 
> Surely a sensible requirement would be that in the absense of an indication that a client can handle any content-encoding other than identity, the identity encoding MUST be used.
> 
> Otherwise we place a requirement on all clients to add Accept-Encoding: identity to all requests, which is mindless bloat.
> 
> Or am I reading this wrong?

Some background here:
  http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/

Cheers,


--
Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 22 June 2011 09:19:22 GMT

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