- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Mon, 17 Mar 2014 09:28:53 +0100
- To: "Willy Tarreau" <w@1wt.eu>
- Cc: "William Chan (?????????)" <willchan@chromium.org>, "Amos Jeffries" <squid3@treenet.co.nz>, "HTTP Working Group" <ietf-http-wg@w3.org>
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 Regards, -- Nicolas Mailhot
Received on Monday, 17 March 2014 08:29:40 UTC