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

Re: current HTTP/2 spec prevents gzip of response to "Range" request

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Wed, 26 Mar 2014 08:28:15 +1000
Message-ID: <CACweHND1EYzPOQFqPkQL5q1V+KYeaW3GvzxLn6m0QyTwYfOUEg@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: K.Morgan@iaea.org, "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 26 March 2014 05:54, Patrick McManus <pmcmanus@mozilla.com> wrote:

> I'm unlikely to implement a gzip transfer encoding decoder any time soon.
> The distinction between TE and CE is too confusing and I think we're better
> off without the footgun and just using a single defacto CE mechanism
> instead (with all its admitted warts).

The fact that one of these "warts" is that people think CE is a transport
 is one that I strongly believe we should not perpetuate.

HTTP/2 is a brand new transport, surely it will only help to clarify the
issue if we discuss, codify, and/or revise transfer codings, and completely
doesn't mention content codings. People might see it and think "oh, TE is a
transport thing, and CE isn't". Maybe.

Incidentally, is not the current implementation of CE:gzip effectively a
"gzip transfer encoding decoder" anyway? Surely that would be *easier* to
scavenge than implementing a whole new binary, header table based, huffman
coded, bells and whistles transport mechanism. Of course, I says it as
shouldn't, since I don't know the Firefox codebase at all.

> The mandatory implied Accept-Encoding codifies a well worn and useful
> optimization.. Transfer-Encoding doesn't have the same track record to
> justify adding it at the same level.

It's not at the same level; CE is above TE. Making claims in HTTP/2 about
CE is too close to modifying existing protocol semantics for my liking,
whereas TE is exactly the space in which we're working. And like I said,
we're already completely rewriting the entire transport mechanism; adding
compression is hardly out of place.

Put glibly: a binary wire format for HTTP doesn't have *any* track record
at all, but we're adding that.

  Matthew Kerwin
Received on Tuesday, 25 March 2014 22:28:44 UTC

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