Re: TE request header deployment

[Roland Zink <[e-mail]>]

When data is dynamically compressed for transport then content-encoding 
is often broken and using transfer encoding would be better. As far as I 
know the support was removed from browsers and web servers because if 
both are supported then content was often compressed twice.

For downstream the negotiation shouldn't be a problem but upstream I 
think this isn't defined. You probably need something like CICE 
(https://tools.ietf.org/html/rfc7694) for transfer encoding or you just 
know (for example by configuration) that you can use it.

Regards,

Roland



Am 01.07.2016 um 13:09 schrieb Amos Jeffries:
> On 1/07/2016 2:05 p.m., Adrien de Croy wrote:
>> Hi all
>>
>> I've been trying unsuccessfully to find a browser that sets TE header in
>> requests.
>>
>> Tested IE, Chrome, Firefox and Opera current versions.
>>
>> I note that the wikipedia page for it comments that due to some
>> unreliable servers (e.g. breaking on TE headers) that browsers now
>> tended to not use it.
>>
>> Is it a completely defunct header then?  We were thinking it could be a
>> good option for reverse proxy bandwidth reduction (apart from HTTP/2 of
>> course).  Pointless if nobody is using it, and even worse if the proxy
>> would have to retry if the server broke on it (e.g. if a proxy inserted
>> it for upstream).
>>
>> Regards
>>
>> Adrien de Croy
> FWIW The Squid eCAP plugin to enable gzip encoding uses it on server
> connections.
>
> Other than that it seems to be a big empty space.
>
> For HTTP/2 there is
> <https://tools.ietf.org/html/draft-kerwin-http2-encoded-data-08> which
> unfortunately does not show up on the WG tracker page of related drafts
> for some reason.
>
> Amos
>
>