W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Using HTTP Trailers [was: Content-Integrity header]

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Wed, 11 Jul 2012 20:43:55 -0500
Message-ID: <CACuKZqHQ1rEc-B9cscD55SAVoHp8rE4aovPeLg3ASNgUYxgOCw@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Intermediaries are required to decompress a gzip transfer-coding?

Intermediaries are forbidden to decompress gzip content-coding to look
into the content? Intermediaries are forbidden to change
Accept-Encoding and Content-Encoding?

On Wed, Jul 11, 2012 at 7:15 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 12.07.2012 09:59, Zhong Yu wrote:
>> Transfer-Encoding and Content-Encoding overlap in functionality. For
>> example, gzip can be done in either way. But in reality, gzip is only
>> implemented with Content-Encoding, for whatever reason. It might be
>> safer to introduce a new content-coding than a new transfer-coding.
> The Content-Encoding is about the entity. End-to-End.
> The Transfer-Encoding is about the channel. Hop-by-Hop.
> gzip is not implemented as Transfer-Encoding due to all the reasons Willy
> and I put forward against mandatory gzip compression on SPDY connections. It
> is a large performance loss to de/re-compress at every hop. chunked on the
> other hand is trivial to recode and when used right increases performance.
> When implementing anything which intermediaries *need* visibility to and
> possibly even manipulation of, Content-Encoding is the worst way to do it.
Received on Thursday, 12 July 2012 01:44:23 UTC

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