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 <http://stackoverflow.com/users/17174/sam-saffron>Saffron<http://stackoverflow.com/users/17174/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.
Received on Tuesday, 25 February 2014 14:32:27 UTC