- 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>
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