W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Transfer-codings, mandatory content-coding support and intermediaries

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Tue, 22 Apr 2014 10:22:53 +1000
Message-ID: <CACweHNA3J4aW4mFPLf6rfZXhYFQEGkSmyFM+CMW8DZoDxRgJkQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Patrick McManus <pmcmanus@mozilla.com>, K.Morgan@iaea.org, Mark Nottingham <mnot@mnot.net>, Julian Reschke <julian.reschke@gmx.de>, Daniel Stenberg <daniel@haxx.se>, HTTP Working Group <ietf-http-wg@w3.org>, C.Brunhuber@iaea.org, Roland Zink <roland@zinks.de>
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
Received on Tuesday, 22 April 2014 00:23:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC