- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 17 Mar 2014 09:49:16 +0100
- To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Cc: "William Chan (?????????)" <willchan@chromium.org>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Mar 17, 2014 at 09:28:53AM +0100, Nicolas Mailhot wrote: > > Le Ven 14 mars 2014 23:36, Willy Tarreau a écrit : > > On Fri, Mar 14, 2014 at 03:22:01PM -0700, William Chan (?????????) wrote: > >> Correct. But IIUC, the problem is the client doesn't know if there's a > >> 1.0 > >> intermediary or backend in the path, or if the 2.0 gateway is willing to > >> buffer (sounds crazy, but just for completeness I mentioned it). So the > >> client can't assume gzip support at the peer, even though we suspect > >> most > >> would support it. Since we can't assume by default, I was thinking maybe > >> we > >> can assume by having the server/proxy explicitly declare support. > > > > Another point is that I'm suspecting that gunzip on 2.0->1.x gateways will > > be disabled because of seucrity issues. It's so much easy to exploit > > random > > decompressors for size amplification that I'm having a hard time imagining > > that this will remain enabled for a long time :-/ > > I doubt it. If http/2 is gzip all security gateways will run gunzip by > default to scan for malware. So I can't fathom why they would disable it > for the 2.0???1.x case We're really not speaking about the same gateways. You're speaking about client-side proxies, I'm speaking about server-side gateways and load balancers. Also, the cost of gunzip vs malware analysis is minimal. However, the cost of gunzip vs forwarding is huge, especially when it involves using the gateway as an amplifier. Willy
Received on Monday, 17 March 2014 08:51:22 UTC