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

Regards

Adrien


------ Original Message ------
From: "Roland Zink" <roland@zinks.de>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 
>(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
>>
>>
>
>

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