I have a suggestion on improving http_gzip_filter_module and want to discuss with you: Currently most browsers support both the gzip and deflate compression methods, and the algorithms of gzip and deflate are almost the same, except that the deflate compression removes an 18 bytes header. In order to save bandwidth, I hope to add a 'gzip_deflate' option which could support deflate compression when enabled. Default value is Off. Any ideas?
on 2008-12-30 03:22
on 2008-12-30 08:03
My readings of the applicable RFCs (2616, 1950, 1951, and 1952) indicate that you can't just "strip" the header off a proper RFC-compliant gzip stream and call it "deflate". The "gzip" compression is a RFC 1952 gzip stream which may contain one or more members. The "deflate" compression is an RFC 1950 zlib + RFC 1951 deflate stream, which differs from a "raw" RFC 1951 DEFLATE stream. I realize that many popular web servers simply send a RFC 1951 stream, but in my opinion, if it's added to nginx, it ought to be done right. :) I've not looked at the relevant code yet, but getting a zlib stream instead of a gzip stream should be easy enough, in the end. Also, due to the fact that a zlib stream is "simpler" than a gzip stream, many implementations of zlib are actually faster (though potentially a tiny bit larger in terms of total data). So, instead of a separate 'gzip_deflate' directive, I'd like to see it implemented as "always on" (in case a User Agent only requests deflate for some reason). Then the gzip directive could be modified to have 3 options: Off; On (same as 'prefer_gzip'); and 'prefer_deflate' (for those sites which prefer the efficiency over the potential < 10% bandwidth savings). Potentially, there could also be a 'never_deflate' option to the gzip directive. Honestly, I can't see a huge reason for this, myself. By changing the gzip directive, any upgrading sites would "automagically" get the new feature while allowing sites to fine-tune their outgoing content. And all without yet-another-directive. And it could be documented akin to gzip_proxied: gzip syntax: gzip off|prefer_gzip|prefer_deflate|on default: gzip off context: http, server, location, if (x) location Enables or disables gzip compression. * off - disables compression for all requests * prefer_gzip - sends gzip content to user agents who can accept both gzip and deflate content * prefer_deflate - sends deflate content to user agents who can accept both gzip and deflate content * on - synonym for "prefer_gzip". For backwards-compatibility with older versions But count this as a message in support of the feature (else I would not have bothered typing so much). I'd just like to see it implemented in a way that is as useful as possible, and without mimicing "other" web servers' buggy behaviors. Warmest, --Matt -------------------------------------------------- From: "Paul Gao" <email@example.com> Date: Monday, December 29, 2008 6:13 PM To: <firstname.lastname@example.org> Subject: about add deflate support to http_gzip_filter_module
on 2008-12-30 20:21
<matt@...> writes: > Enables or disables gzip compression. > > * off - disables compression for all requests > * prefer_gzip - sends gzip content to user agents who can accept both > gzip and deflate content > * prefer_deflate - sends deflate content to user agents who can accept > both gzip and deflate content > * on - synonym for "prefer_gzip". For backwards-compatibility with older > versions > This is even better, and I hope this feature could be implemented in the near future.