On 22 April 2014 08:34, William Chan (陈智昌) <willchan@chromium.org> wrote: > +1 > > On Mon, Apr 21, 2014 at 6:24 AM, Patrick McManus <pmcmanus@mozilla.com>wrote: > >> >> I support keeping the implicit CE gzip and not doing anything regarding >> TE or hop-to-hop encodings for reasons discussed previously. >> >> > T-E aside (because I think it's clear where I stand on that), I'm strongly against keeping implicit C-E gzip. Reasons for it: P1. Lazy intermediaries have no way to strip it from the accept-encoding headers. True, evil virus scanners might do this, clogging up the tubes for no good reason; but there are also some legitimate use-cases for stripping the header, e.g. con #2, below. P2. Browsers save ~5 bytes in accept-encoding headers. Slightly facetious, but it is a benefit... Reasons against it: C1. It puts no burden whatsoever on origins to send C-E. Lots of clients already explicitly accept gzip-- which has lead to the pathological case of intermediaries adding it. Forcing people to accept the encoding will likely only encourage intermediaries to keep on doing the wrong thing. Naive non-origin compression is the basis of the all security concerns I've heard surrounding compression. C2. It *breaks* the protocol in one edge case, where a HTTP/1.1 request to a gateway includes Cache-Control:no-transform, and does not include Accept-Encoding:gzip. We haven't given intermediaries an out, apart from some sort of ugly 5xx (maybe 502?), and we certainly haven't blessed them to ignore the no-transform. C3. From my ivory tower: this change to a non-transport header does not belong in HTTP/2. Modifying semantics to "improve" the way people use the web is way outside the charter. -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Tuesday, 22 April 2014 00:23:28 UTC