Re: h2#404 requiring gzip and/or deflate

We clarified this in HTTPbis - see <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-4.2.2>.

The downside of only doing gzip is that if a server *does* use deflate, a HTTP1->2 intermediary will have to re-encode responses. Not saying that's a showstopper, just noting it.



On 26 Feb 2014, at 1:32 am, Jesse Wilson <jesse@swank.ca> wrote:

> 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 checksum)."
> 
> [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 zlib.
> 
> 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 Saffron on 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."
> 
> [3]: http://stackoverflow.com/questions/388595/why-use-deflate-instead-of-gzip-for-text-files-served-by-apache
> 
> My preference is to avoid this rats nest and require gzip only.
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 25 February 2014 20:38:09 UTC