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