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 21:54:43 -0500
Message-ID: <CACuKZqF3JrEUOrmrfJki+Kmib-TLjx+P3FchTKdjQLMwFMkOyw@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
If there's not an official policy mandating different use of the two,
I don't see any essential technical difference between transfer coding
and content coding.

  TE: gzip
  Transfer-Encoding: gzip chunked

works equally well as

  Accept-Encoding: gzip
  Content-Encoding: gzip

for anyone on the path.

On Wed, Jul 11, 2012 at 9:27 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 12.07.2012 13:43, Zhong Yu wrote:
>> Intermediaries are required to decompress a gzip transfer-coding?
> Yes. Transfer Encoding must be removed when caching, when transforming, when
> interpreting the body, or when transcoding to a hop with different
> negotiated Transfer-Encoding type.
> There is a very limited set of middleware (essentially just SOCKS or VPN
> tunnels) which can avoid it. All the rest have to implement the encoding.
>> Intermediaries are forbidden to decompress gzip content-coding to look
>> into the content? Intermediaries are forbidden to change
>> Accept-Encoding and Content-Encoding?
> Why do you insert this word "are forbidden to"?
> It is a *performance* loss issue, not a permission one, for the large
> majority of intermediary types which do not need to touch the entity
> integrity in any way. Just look at how many of the transforming proxies that
> do content filtering find it necessary to force identity encoding from
> servers just to operate at any reasonable speed.
Received on Thursday, 12 July 2012 02:55:11 UTC

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