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

Re: Support for gzip at the server #424

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Sun, 16 Mar 2014 08:35:27 +0200
To: William Chan <willchan@chromium.org>
Cc: James Cloos <cloos@jhcloos.com>, Roberto Peon <grmocg@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>, Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20140316063121.GA3145@LK-Perkele-VII>
On Sat, Mar 15, 2014 at 09:32:21PM -0700, William Chan (ι™ˆζ™Ίζ˜Œ) wrote:
> On Mar 15, 2014 7:45 PM, "James Cloos" <cloos@jhcloos.com> wrote:
> >
> > It seems from all of this that the /real/ bugs are using the gzip CE for
> > anything which is not already gzip(1)-compressed on disk, and http/2's
> > flawed idea of making any non-transparent CE implicit.
> >
> > Changing how CE works clearly breaks things and lacks any real benefits.
>
> I must be missing something. There's no implicit content encoding, is
> there? I thought it was implicit accept encoding.

Correct. The spec clearly says that if implicit A-E gzip is used, it MUST
be properly marked via C-E (and the same goes for any explicit A-E entries
server uses).

Quoting latest git master of the spec:
> "A compressed response MUST still bear an appropriate content-encoding
> header field."


-Ilari
Received on Sunday, 16 March 2014 06:35:54 UTC

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