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: Sun, 30 Mar 2014 11:40:04 +1000
Message-ID: <CACweHNBuNZBcc1YsFirmrfq2VcVQXYw8KOkWQ3g1PMX3fi6mPQ@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, roland@zinks.de, C.Brunhuber@iaea.org, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 30 March 2014 08:42, <K.Morgan@iaea.org> wrote:

> On Mar 28, 2014, at 13:36, "matthew@kerwin.net.au<mailto:
> matthew@kerwin.net.au>" <matthew@kerwin.net.au<mailto:
> matthew@kerwin.net.au>> wrote:
> > 
> ... I say leave the Content-Encoding part out of it, since that's covered
> elsewhere, and say something along the lines of "TE headers exist, and some
> of them include 'gzip'."
> That was exactly our original motivation to start this thread! Transfer
> codings and their associated headers (i.e. TE, Transfer-Encoding) are
> forbidden by the HTTP/2 spec. That's what we'd like to see, at a minimum,
> changed...
> from Section 8.1.3: "intermediaries SHOULD also remove other
> connection-specific header fields, such as ... Transfer-Encoding ..."

Yes, they should. Those headers are messages to the intermediaries, not
to the endpoints; they shouldn't be propagated.

from Section 8.1.3: "...the TE header field, which MAY be present in an
> HTTP/2 request, but when it is MUST NOT contain any value other than
> "trailers"..."

This is the whole crux of the issue. I'm not sure what motivated this
ruling, but I assume that it was mostly that the only usage of TE, aside
from "trailers", was for compression, and in the earlier versions of the
draft hop-by-hop compression was handled by a flag instead of negotiation
header. Then, having effectively removed transport headers from the
protocol, i.e. leaving the HEADERS frame and header tables full of
higher-level, end-to-end concerns (and I consider "trailers" an end-to-end
concern, for practicality reasons), other conveniences may emerge, like a
higher chance of retransmitting unmodified HEADERS frames, or even just
clarity of the spec.

To that end I suggested a new frame type for hop-by-hop/transport headers
(or a flag in the HEADERS frame, which amounts to essentially the same

Having a header allows us to negotiate compression (without mandating
support, unlike a flag), and allows experimentation and the introduction of
new things (TE: bzip2? Some new HH-style hints?). And having a distinct
frame type allows people to easily distinguish them from regular headers,
making them easier to ignore if that's your thing, and still allowing those
other conveniences. With a new frame type we can then reintroduce
TE/Transport-Encoding without hurting anybody.

  Matthew Kerwin
Received on Sunday, 30 March 2014 01:40:33 UTC

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