Re: #445: Transfer-codings

On 5/04/2014 10:29 a.m., Matthew Kerwin wrote:
> On Apr 5, 2014 6:47 AM, "Michael Sweet" <msweet@apple.com> wrote:
>>
>> Matthew Kerwin:
>>>
>>> Michael Sweet:
>>>>
>>>> First, why a separate flag when you can just look at a couple bytes in
> the DATA?
>>>
>>> Which bytes? Are you suggesting magic number heuristics? Or extra
> metadata packed into DATA frames?
>>
>> If I understood your proposal correctly, your TE field is always in bytes
> 4-5 of the DATA frame.
> 
> "This field is optional and is only present if the ENCODED flag is set."
> 
> Otherwise everyone would pay a 2-byte tax for something only a few use.

Unless that tax were perhapse the incentive for implementations to
encode data more securely than plain identity encoding? while still
allowing identity encoding (value 0x0000) to be used.

> 
>>>> And finally, HTTP/2 is not supposed to introduce new semantics.  If you
> have TE: gzip/compress/zlib, then that needs to be proposed separately
> since it applies equally to HTTP/1.1 and HTTP/2.
>>>
>>> No, the only time TE applies equally to HTTP/1.1 and HTTP/2 is if a
> 1.1<->2 gateway blindly forwards transfer-encoded data; but they're not
> even meant to do that in the 1.1<->1.1 case. TE is a hop-by-hop header.
>>
>> Given some of the security concerns that have been voiced on this list, I
> think it would be reasonable for a gateway to forward gzip'd data provided
> that the other end supports it, but not to introduce gzip since the gateway
> probably lacks the context needed to know it is safe to compress.
> 
> Indeed. I guess that since -- as Ilari and mnot pointed out -- this differs
> from TE in the compression contexts, it makes it hard for a 2->1.1 gateway,
> and even harder for a 1.1->2. That's an issue with this propsal, which is
> hard to address nicely.

Not much more so than with the current draft. Gateways are forced to
uncompress and send as identity+chunked in HTTP/2 at present.

Also, why would a 2->1.1 gateway go to the trouble of compressing ?

The presence of a HTTP/2 hop anywhere in the path is likely to result in
*less* usage of compressed data. More bandwidth waste overall.

Amos

Received on Saturday, 5 April 2014 06:17:30 UTC