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

Re: #445: Transfer-codings

From: Michael Sweet <msweet@apple.com>
Date: Fri, 04 Apr 2014 17:13:28 -0400
Cc: Matthew Kerwin <matthew@kerwin.net.au>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <0C2D1721-8ACD-4899-8275-FF5F27399658@apple.com>
To: Martin Thomson <martin.thomson@gmail.com>

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

Received on Friday, 4 April 2014 21:13:59 UTC

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