- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 21 May 2013 14:24:04 -0700
- 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