Musings

Amazingly … it works!

No longer do child httpd processes go berserk after a while, and start hogging all the available CPU time. Instead, individual httpd processes barely ever rise as high as 0.1% of a single CPU when actively serving pages. Which is the way it’s supposed to work. So I’m now (more or less) happily running Apache/2.3.0-dev.

Let’s review: Apache 2.2.0 is broken and unusable on MacOSX 10.4; the current Development snapshot (from barely 2 weeks after the 2.2.0 release) works just fine. After the previous debacle of Apache 2.0.x (for x<55) being utterly broken on MacOSX 10.4, I begin to get the impression that no one, either at the Apache Foundation or at Apple, actually tests them together before release.

“Smart” Filters

Anyway, now that’s out of the way, we can turn to my next “Huh?” moment with the new Apache release.

Some of my pages use server-side includes. I also use mod_deflate to send out my pages compressed, thereby saving bandwidth while speeding them on their way to you, dear reader. The configuration code to do this is very simple.

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

AddOutputFilterByType DEFLATE text/html text/plain \
    application/rss+xml application/atom+xml \
    application/xhtml+xml application/xml \
    application/postscript image/svg+xml

But Apache 2.2 comes with a new, improved, filtering architecture, mod_filter. And what do they have to say about AddOutputFilterByType?

One further directive AddOutputFilterByType is still supported, but may be problematic and is now deprecated. Use dynamic configuration instead.

Deprecated, eh?

OK … Let’s figure out how to do this the “right” way. Something like

AddType text/html .shtml
AddHandler server-parsed .shtml
FilterDeclare SSI
FilterProvider SSI INCLUDES Handler server-parsed

FilterDeclare COMPRESS
FilterProvider COMPRESS DEFLATE resp=Content-Type $text/html
FilterProvider COMPRESS DEFLATE resp=Content-Type $text/plain
FilterProvider COMPRESS DEFLATE resp=Content-Type /application\/.*xml/
FilterProvider COMPRESS DEFLATE resp=Content-Type $application/postscript
FilterProvider COMPRESS DEFLATE resp=Content-Type $image/svg+xml
FilterProtocol COMPRESS change=yes

FilterChain SSI COMPRESS

Except that doesn’t actually work.

Well … it works OK on non-SSI pages. But SSI pages, like the main page of this blog, involve internal subrequests, and they get hopelessly spooged by the above filter-chain.

So maybe some Apache maven can explain how the wizzy new smart filtering technology is supposed to accomplish this garden-variety task? Or, better yet, maybe they could add such an explanation to the f#@%ing documentation!