Re: #445: Transfer-codings

Matthew,

On Apr 4, 2014, at 4:00 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> On Apr 5, 2014 5:33 AM, "Michael Sweet" <msweet@apple.com> wrote:
> >
> > -1 on this.
> >
> > 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.
> ...
> 
> > 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.
> 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.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair