- From: Roland Zink <roland@zinks.de>
- Date: Fri, 1 Jul 2016 13:43:18 +0200
- To: ietf-http-wg@w3.org
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 11:43:51 UTC