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

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
thing).

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
  http://matthew.kerwin.net.au/