Lighttpd url rewrites are funny

Mar 20 ’06

Since I've been playing around with RoR I've found the

script/server

trick for development to be fantastically useful. It's quick to use, the server itself is fast, and it's everything I could want. That is, until it's time to go in to production mode. I've been running Apache, using OSX's built-in build, but I'm considering switching my whole setup over to lighty because of the funkiness of Apache and Ruby's fcgi. So I tried it. Building lighty was really easy. Getting lighty to then serve my static pages was also very easy. Then I tried getting it to serve my ruby apps, and that's where the problems hit.

It turns out that my one big config problem was this: "url.rewrite" does not work inside a $HTTP["url"] matching block. So, for example consider this case, where I want to rewrite URL's intended for my rails app which has 2 controllers, admin and view:

$HTTP["url"] =~ "^/input_path/" {
  url.rewrite-once ("/(admin|view)/(.*)" => "/some/other/path/$1/$2")
}

If the incoming URL matches "/input_path/" then lighty starts processing the code inside the braces, but the url.rewrite-once fails to act. Instead, the server will invariably look for files inside /input_path/ and serve up a 404.

The proper way to do this sort of work with lighty is to have the regex do all the work:

url.rewrite-once ("^/input_path/(admin|view)/(.*)" => "some/other/path/$1/$2")

This isn't documented anywhere on the lighty web site, but there is a message on the lighty mailing list that points out the problem.

I have to say, other than this hitch, I've been very impressed with the speed and ease of configuration that lighty offers. Once I get PHP to work with it, I'll be a happy camper.