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

Re: h2#404 requiring gzip and/or deflate

From: Jesse Wilson <jesse@swank.ca>
Date: Tue, 25 Feb 2014 09:32:00 -0500
Message-ID: <CAME=j1kd4GX=iGuwb+mkKivzaNR9ocjcmD8r+zw1s1jTVvVVqw@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: Mark Nottingham <mnot@mnot.net>, Zhong Yu <zhong.j.yu@gmail.com>, Roberto Peon <grmocg@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
In Billy Hoffman's blog[1], and elsewhere, there's discussion over the fact
that 'deflate' is used to describe two different algorithms. And several
browsers and webservers got it wrong.

"So, DEFLATE, and Content-Encoding: deflate, *actually means the response
body is composed of the **zlib** format* (zlib header, deflated data, and a

[1]: http://zoompf.com/blog/2012/02/lose-the-wait-http-compression

If the spec is going to require that clients support deflate compression,
it should use strong language to remind implementors that 'deflate' means

And if 'deflate' is implicit, then middleboxes that bridge HTTP/2 clients
to HTTP/1.1 servers will need to transcode/decompress deflated data for the
legacy browsers[2] that misinterpret the spec.

[2]: http://www.vervestudios.co/projects/compression-tests/results

Plus, middleboxes that bridge HTTP/1.1 servers to HTTP/2 clients may need
to transcode/decompress deflated data from broken servers that also get the
APEC wrong.

Otherwise all HTTP/2 clients will need to use heuristics to guess which
algorithm the peer is using. From Sam
Stack Overflow[3]:

"So, over the years browsers started implementing a *fuzzy logic* deflate
implementation, they try for zlib header and adler checksum, if that fails
they try for payload."


My preference is to avoid this rats nest and require gzip only.
Received on Tuesday, 25 February 2014 14:32:27 UTC

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