W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #445: Transfer-codings

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Sat, 5 Apr 2014 07:29:40 +1000
Message-ID: <CACweHNDfRr_jrxfue7TBq5g_a826jpkGMwWcx1B+cZdFgO0GsA@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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.

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

>> HTTP/2 is explicitly supposed to alter transport, and TE is a transport
issue. That's why it's ok (but deficient) that the current draft alters
what's allowed in TE headers.
> The current draft stops the use of "TE: chunked" because all HTTP/2 data
is chunked.  That doesn't alter semantics or pose additional security
considerations, and there is a clean mapping to/from HTTP/1.1.

The current draft forbids all TE but "trailers", and I think that one's
allowed because it makes gateways' lives bearable. That's one kind of clean
mapping, I suppose.
Received on Friday, 4 April 2014 21:30:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC