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

On 23/06/11 11:41, 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.
>
> 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.

Indicating that proxies SHOULD only upgrade. Adding encodings they can 
translate down to one of the known clients acceptable ones.

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

For a _proxy_ this is not a problem. For a content filter it likely is.

Then again you can look at the rollout of sdch and xpress encodings as a 
case study on encodings the middleware is not knowing about.

AYJ

Received on Thursday, 23 June 2011 06:52:15 UTC