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

OK, I can see how the definition kinda works in 2616, but there's a problem.

what happens when someone rolls out a new encoding?

That means you need to update ALL clients now to exclude it if it's not 
supported, if they were relying on lack of the header.

Otherwise you need to add Accept-Encoding to all requests = bloat.

What about HTTP/1.0 clients?  Surely they don't send Accept-Encoding, 
and a server can't use Content-Encoding in responses?

Just seems a bit backward to me to have the default (no header) mean 
everything, including the unknown.

If C-E had already been rolled out, maybe those deployments should have 
been fixed.  Too late now I guess so we live with the bloat.  What it 
means I guess though is that even if a filter that previously would have 
stripped the A-E header instead inserts A-E: identity, it still can't 
rely on getting that back as the server gets to make the final decision, 
it's only a should requirement to send back a 406.

Makes for fun when a proxy down-grades a request (wrt A-E) which then 
gets bounced by the Origin Server because of the downgrade.

Which then means proxies really shouldn't mess with A-E, and need to 
support all encodings, including all the filters in their processing chain.

Adrien


On 23/06/2011 10:09 a.m., Roy T. Fielding wrote:
> 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
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 22 June 2011 23:42:15 UTC