I was surprised to learn that Debian's apache2 package does not enable mod_deflate by default. This is the module which implements compression.

Once enabled, I needed to add application/atom+xml to the configuration in order for it to apply to atom feeds (which are the most consistently fetched URI on my site generally, although right now the image from my last log post is in the lead by a huge margin).

I'm not sure how much merit there is in compressing atom feeds. My primary one is 4.8k in size and compressed to roughly 1.6k at the time of writing. The difference in time for fetching those two sizes is dwarfed by connection setup/tear-down and possibly by the CPU time used for compression. I wonder if mod_deflate caches the compressed copies? Since my feed (and entire site) is statically generated by ikiwiki, I could generate compressed copies once at build-time. Perhaps apache2's content negotiation could be configured to serve these up.


To answer a couple of questions: (1) mod_deflate doesn't cache anything. But mod_cache does, if you enable it. However, you need to be aware of bugs in ETag handling that may defeat cacheability of compressed pages. (2) If you have pre-existing compressed and uncompressed versions, apache will do the right thing out-of-the-box. RTFM mod_negotiation and multiviews for the gory detail.

Is this thing a wiki I'm editing? If so, do I need to mention I'm http://bahumbug.wordpress.com/?

bahumbug [wordpress.com],
The reason why mod_deflate is not enabled by default is simply that it interacts badly with some version of Internet Explorer. -- http://np237.livejournal.com/

Some recent versions of Apache 2.2 have a bug in the filter module which causes etags for compressed content to get "-gzip" appended on the outgoing header, and when it get compared to the actual etag value, it doesn't match, preventing 304 responses, which I would consider worse than uncompressed data. However, I do value efficiency, so I use NGINX as a gzip filtering proxy. -- http://www.docunext.com/