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

Re: Design Issue: GZIP flag on DATA Frames

From: James M Snell <jasnell@gmail.com>
Date: Tue, 21 May 2013 14:24:04 -0700
Message-ID: <CABP7RbfynEZ--QMvyXmsGvqKDv2T9CbVCuBfVexNtmTa5_U_pQ@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Roland Zink <roland@zinks.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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:24:51 UTC

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