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

Hi Matthew-

On Wednesday,26 March 2014 05:06, Matthew Kerwin wrote:
> That said, I'm pretty strongly for supporting the negotiation in the first place.
> Maybe it needs to be something that's clearly a part of HTTP/2, freeing it from the
> stigma attached to the existing TE/Transfer-Encoding headers.

That would work too. We aren't married to the idea of using the TE/Transfer-Encoding headers. We just thought the trickle-down effect (to quote Ronald Reagan) might be beneficial.  If clients (e.g. browsers) support HTTP/2, then they would have to support TE.  Once browsers support TE then slowly HTTP/1.1 servers might start supporting Transfer-Encoding.

> After much deliberation I have a crazy idea: introduce a new frame type for hop-by-hop headers.
> I can think of a couple of benefits:
> * It would be easier to clearly distinguish hop-by-hop and end-to-end concerns (e.g. hopefully help clear up some of the CE/TE confusion).
> * It would provide more flexibility than, say, a settings parameter or a flag in a data frame, by allowing the same type of coding negotiation currently allowed in HTTP.
> * It would be extensible, allowing experimental headers, not unlike HH from [draft-nottingham-http-browser-hints-05].
> * It also makes it easier for people to ignore them ;)

I think we'd be happy with Transfer-Encoding, a flag in an existing frame type or an entirely new frame type.

One question though, this idea to use a frame type for _hop-by-hop_ headers seems to contradict what you said on Tuesday,25 March 2014 23:25: "Also, because TE is hop-by-hop I risk some intermediary terminating the compression, possibly negatively impacting my site's responsiveness ..."
Wouldn't the ideal answer be some sort of end-to-end transfer encoding?

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 Wednesday, 26 March 2014 17:06:57 UTC