Re: TE request header deployment

OK, thanks everyone, as I suspected putting support in for reverse proxy 
on the client-side connection would only affect a very small number of 
clients (e.g. those behind squid with that option enabled), so not worth 



------ Original Message ------
From: "Roland Zink" <>
To: "" <>
Sent: 1/07/2016 11:43:18 p.m.
Subject: Re: TE request header deployment

>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 
>( for transfer encoding or you just 
>know (for example by configuration) that you can use it.
>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 
>>>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 
>>>good option for reverse proxy bandwidth reduction (apart from HTTP/2 
>>>course).  Pointless if nobody is using it, and even worse if the 
>>>would have to retry if the server broke on it (e.g. if a proxy 
>>>it for upstream).
>>>Adrien de Croy
>>FWIW The Squid eCAP plugin to enable gzip encoding uses it on server
>>Other than that it seems to be a big empty space.
>>For HTTP/2 there is
>><> which
>>unfortunately does not show up on the WG tracker page of related 
>>for some reason.

Received on Friday, 1 July 2016 21:17:05 UTC