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

On Thu, 23 Jun 2011, Adrien de Croy wrote:

>
> 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.

Well, there is a MAY there, so if the server wants to always serve a CE 
not supported by the majority of clients, that's its (bad) choice.

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

Most people inspect the UA string in that case (but omit to send a Vary: 
header... if there are different encodings available).

> 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.

Proxies don't need to know about the A-E/C-E, unless they want to inspect 
the payload. (as opposed to TE/T-E), they just shouldn't mess with it...

> 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
>> 
>> 
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 23 June 2011 09:12:30 UTC