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

[Matthew Kerwin <[e-mail]>]

On 26 March 2014 12:02, Patrick McManus <[e-mail]> wrote:

> Hi Matthew,
>
> On Tue, Mar 25, 2014 at 6:28 PM, Matthew Kerwin <[e-mail]>wrote:
>
>> \Surely that would be *easier* to scavenge
>>
>
> my reticence is not about implementation complexity in my client.
>

I understand. Sorry.

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.
>>
>
> I'm sorry to have created confusion. I mean I don't support the same level
> of conformance (i.e. the suggested MUST decode) - not the same level in the
> application. as I say, I'm pretty neutral on defining negotiation of it.
>

That makes sense. In that case I don't disagree; forcing it with a
MUST-level requirement, or even a SHOULD, is not the right approach. Maybe
a best practice guideline, if it's decided that it is, in fact, best
practice.

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.

After much deliberation I have a crazy idea: introduce a new frame type for
hop-by-hop headers.

As far as I can see, we've eliminated connection headers (and the
Connection header) from HTTP/2, with the exception of "TE: trailers", and I
don't think it's necessarily appropriate to reintroduce them, at least not
through the HEADERS frame.

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 ;)

Does anyone have a reason (aside from YAGNI) that we wouldn't want to
pursue this new frame type?

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/