Subject: Re: TE request header deployment

From: Amos Jeffries <[email-masked]>
Date: Fri, 1 Jul 2016 23:09:04 +1200

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

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 1 Jul 2016 13:42:20 +0200 (CEST)

> I've been trying unsuccessfully to find a browser that sets TE header in 

Not a browser, but curl/libcurl supports it client-side. Although I assume it 
is only used once in a blue moon.

-- 

  / daniel.haxx.se

---

From: Roland Zink <[email-masked]>
Date: Fri, 1 Jul 2016 13:43:18 +0200

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

---

From: Cory Benfield <[email-masked]>
Date: Fri, 1 Jul 2016 13:18:49 +0100

> On 1 Jul 2016, at 12:42, Daniel Stenberg <[email-masked]> wrote:
> 
>> I've been trying unsuccessfully to find a browser that sets TE header in requests.
> 
> Not a browser, but curl/libcurl supports it client-side. Although I assume it is only used once in a blue moon.

For that matter, no Python libraries use it by default, and none respect it if the user sets it.

Cory

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 01 Jul 2016 21:16:31 +0000

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" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 1/07/2016 11:43:18 p.m.
Subject: Re: TE request header deployment

>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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 01 Jul 2016 21:22:24 +0000

--------
In message <em3dc07ed5-0128-42b9-9333-7571aa004a6b@bodybag>, "Adrien de Croy" writes:
>clients (e.g. those behind squid with that option enabled), so not worth it.

FWIW, I reached the exact same conclusion with Varnish some years back.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.