Expression parser for Apache

Over the past few days I’ve got a long-awaited round tuit, and given Apache a general-purpose expression parser, ap_expr. That’s in trunk/2.3, and is unlikely to be stable enough for a 2.2.x (release) version for a while.

What I haven’t done this time is write a new expression parser. I’ve done that before, e.g. when I hacked up an ESI parser in 2003, but it’s necessarily an exercise in reinventing the wheel. So this time I’ve just adapted an existing parser: the one used by mod_include. That basically meant removing mod_include-specific stuff from its expression parser, and generalising somewhat. The first stage was complete when mod_include itself was adapted to use ap_expr, and passed all tests with it.

The second module I’ve just now adapted is mod_filter, where the expression parser replaces the ad-hoc dispatch criteria in the FilterProvider directive. The advantage of this is that the updated mod_filter can dispatch on multiple criteria. For example, a user wants a filter to apply if and only if the Content Type is text/html AND the response is not compressed. That’s now easy, and no longer requires hackish workarounds:

FilterProvider myname myprovider "($resp{Content-Encoding} != gzip) && ($Content-Type == /text\/html/i)"

In the medium term, this could be used to enhance a number of different apache functions, and provide a more consistent expression syntax across different modules. Notable potential benefits include a far simpler and more logical configuration syntax for some of the more complex tasks undertaken with mod_rewrite.

Posted on March 31, 2008, in apache. Bookmark the permalink. 4 Comments.

  1. Hello Nick Kew,

    You talked about “hackish workarounds” in this post. Well, I was doing exactly so.. trying to figure how to do the following with:

    To declare a CONTENT_SET Filter, with “change=yes”, that adds DEFLATE to any resp=Content-Type whose Content-Encoding is not yet gzipped,
    but that excludes from the rule : “application/pdf” and “images/.*” (but allows image/svg+xml).

    As I’m using a 2.2.x Apache in production, I can’t afford testing your mod. How would you design such rule with the current mod_filter dispatch criteria?

    FilterProtocol COMPRESS “change=yes”
    FilterProvider COMPRESS DEFLATE resp=Content-Encoding !$gzip
    #now the tricky part:
    # (null)
    #end of tricky part.
    FilterChain +COMPRESS

    Thanks a lot!

  2. In general, you can fix that using rewrite/setenvif if you know details of the response in advance. If you have no information (e.g. in a proxy), mod_filter is your only option.

    Fortunately for you, mod_deflate is an exception to that. It pre-dates mod_filter, and is good at knowing what not to compress. See the docs.

  3. I have currently the same Problem😦

    My Server is crashing with Segfaults and eating many RAM.

    I think mod_deflate will compress another .rar oder similar files, but i cant exclude them😦

    i want this:

    Content-Type /text|xml|javascript/ && Content-Encoding !$gzip

    how can i hack that with mod_filter? I dont see a way😦

  1. Pingback: Flexible configuration for Apache « niq’s soapbox

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: