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

Re: h2#404 requiring gzip and/or deflate

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 25 Feb 2014 12:32:04 -0500
Message-ID: <CAOdDvNo6-oRhHDO_zqqAk3PypfaJS1N+gm5sZiD+cpJojuj73g@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
fwiw I'm fine with just having http/2 imply a single encoding.

On Tue, Feb 25, 2014 at 12:18 PM, Roberto Peon <grmocg@gmail.com> wrote:

> True, and the data Jesse links to seems compelling...
> -=R
> On Tue, Feb 25, 2014 at 9:09 AM, Cory Benfield <cory@lukasa.co.uk> wrote:
>> On 25 February 2014 17:02, Roberto Peon <grmocg@gmail.com> wrote:
>> > There is zero guarantee that http2 would reliably remove any of that
>> logic--
>> > the origin of any particular entity body may be at an HTTP/1 host, which
>> > will use 'deflate'. :/
>> That's not entirely true. The difference between HTTP/1.1 and HTTP/2.0
>> is that in HTTP/1.1 if I send `Accept-Encoding: identity', the server
>> must not return me a compressed response. In HTTP/2.0, however, the
>> server may always return a response compressed with gzip or deflate.
>> This means all HTTP/2.0 user-agents must allow decompression of gzip
>> and deflate encoded responses, because we cannot reliably inform
>> upstream that we don't want them.
>> Jesse and I want to step that back to say that servers may always
>> return a response compressed with gzip only: any other compression
>> must be explicitly requested. In this sitatuion, if I then send
>> `Accept-Encoding: gzip' I'll only ever get gzip back, even if the
>> origin of the entity body is a HTTP/1.1 host. This would allow me to
>> rip my deflate/zlib code out as I can ensure that it won't be sent to
>> me.
Received on Tuesday, 25 February 2014 17:32:32 UTC

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