W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Design Issue: GZIP flag on DATA Frames

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 21 May 2013 14:36:39 -0700
Message-ID: <CAP+FsNd3gqky+94N3k3rJxiC744+3AU1GhoWc4EHoQDiDip0Mg@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Roland Zink <roland@zinks.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
The proposal does force anything other than gzip to use an alternate code
path for parsing/interpretation, which does not inspire confidence given my
experience with backup-generator problems, and it probably involves writing
*more* code today than the alternative of leaving it where it is in the
HTTP semantic layer.

On Tue, May 21, 2013 at 2:24 PM, James M Snell <jasnell@gmail.com> wrote:

> This does not preclude the use of alternative compression schemes. If
> someone chooses, it would be possible, for instance, to continue using
> accept-/content-/transfer-encoding at the http semantic layer and
> simply not set the GZIP flag on the DATA frame. Having the GZIP flag
> would just provide an approach that would make that unnecessary in the
> most common cases today. If, at some point in the future a new, more
> efficient better compression algorithm overtakes gzip as the
> predominant mechanism, the protocol can be updated to reflect that
> fact (i.e. with a new protocol version string, etc).
> On Tue, May 21, 2013 at 2:17 PM, Bjoern Hoehrmann <derhoermi@gmx.net>
> wrote:
> > * Poul-Henning Kamp wrote:
> >>You forgot half the "worth-while" part:  The compatibility issues.
> >>
> >>Even something as trivial as "deflate" vs. "gzip" was too hard for
> >>some people to get right.
> >
> > I think people will create an even bigger mess if they're forced to work
> > around lack of support for alternative compression schemes in HTTP/2.0.
> > --
> > Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
> >
Received on Tuesday, 21 May 2013 21:37:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC