Re: #445: Transfer-codings

Martin,

On Apr 4, 2014, at 4:31 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 4 April 2014 12:14, Michael Sweet <msweet@apple.com> wrote:
>> My $0.02: Since "Transfer-Encoding: gzip" would apply to both HTTP/1.1 and
>> HTTP/2, we should define gzip in a separate document that applies to both.
>> That would also allow for some needed security discussions in order to make
>> the necessary conformance statements.
> 
> ?
> 
> Transfer-Encoding: gzip is defined for HTTP/1.1 already.

As defined in RFC 2616, the only well-defined TE value in section 3.6 is "chunked".  The others are simply referenced back to the Content-Encoding values in section 3.5 which is confusing to say the least.  The wording in p1-messaging (section 3.3.1) *is* much clearer, but still doesn't address today's security issues surrounding compression.

> HTTP/2 doesn't permit hop-by-hop headers, so it cannot be defined in a
> way that would be applicable to both.

FWIW, the way Transfer-Encoding is defined in p1-messaging, it makes it pretty clear that compression MAY or MAY NOT be end-to-end at the discretion of each recipient in the chain, but it is not explicitly a hop-by-hop header and it definitely is not a frame-by-frame header (which is what is being proposed.)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair