Jesse, That's a good (but unfortunate) point, and one that has also caused interoperability problems for IPP which normatively ties "deflate" to RFC 1951 (raw deflate) and not to RFC 1950 (zlib format) like HTTP/1.1 does... :/ +1 for just requiring gzip and perhaps documenting why deflate isn't being required... On Feb 25, 2014, at 9: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. > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 25 February 2014 18:27:56 UTC