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

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 22 Jun 2011 15:09:27 -0700
Cc: httpbis Group <ietf-http-wg@w3.org>
Message-Id: <877FCD14-2BC3-4A98-A63A-4A130EE9A27E@gbiv.com>
To: Adrien de Croy <adrien@qbik.com>
On Jun 22, 2011, at 2:14 AM, 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.

See the definition of the field.  No Accept-Encoding means send me ANY encoding.
An empty Accept-Encoding field-value means "no encoding".

Accept-Encoding was defined two years after Cotent-Encoding was *deployed*.
There was simply no other possible definition that would work.

....Roy
Received on Wednesday, 22 June 2011 22:09:51 GMT

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