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

On Mar 30, 2014, at 3:40, "matthew@kerwin.net.au<mailto:matthew@kerwin.net.au>" <matthew@kerwin.net.au<mailto:matthew@kerwin.net.au>> wrote:

On 30 March 2014 08:42, <K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>> wrote:

On Mar 28, 2014, at 13:36, "matthew@kerwin.net.au<mailto:matthew@kerwin.net.au><mailto:matthew@kerwin.net.au<mailto:matthew@kerwin.net.au>>" <matthew@kerwin.net.au<mailto:matthew@kerwin.net.au><mailto: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.


I guess it's obvious, but not very clear in the spec - an intermediary can't just remove a transfer coding and not do something about it (i.e. Remove the coding on the payload)

For example, "chunked" has to be converted to h2 framing.

Adding your proposed header type below would allow 1.1 -> 2 intermediaries to simply forward transfer codings besides chunked.

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.


I understand your motivation better now and think it's a fine idea.

Are you up for writing the text and proposing it? (If you do, I think you should start a new thread as its scope is beyond just the purpose of this thread.)

BTW, by "ignore" you mean forward to the next hop right? In other words, you can't just drop a transfer coding header and not do anything about it.


This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Sunday, 30 March 2014 05:12:31 UTC