It’s been a while since I started hearing rumors about LigHTTPd, a new free software web server that is gaining popularity, especially within the dynamic community. For a long time I dismissed it, though. Why the duplication of effort? After all, the free software community already has a very successful web server product - Apache. The problem is that Apache, while being a very complete product, is quite difficult to run. I never felt like I really mastered its configuration, for example - I usually end up just copying examples from other users and adjusting them, hoping that I got it right (and worrying that I probably missed something).

Recently I had to configure a FastCGI application to work in a mixed SSL and plain HTTP environment. Turns out Apache makes it quite difficult - it wont ship SSL as part of the product, and finding out how to configure it turned out to be far from trivial. Also, Apache1, that beloved monolithic monster, does have pretty good support for FastCGI via a module, but Apache2 doesn’t really have any good solution.

A few hours into the adventure I remembered LigHTTPd (pronounced lighty, usually) and thought I might as well give it a try. A quick sudo apt-get install lighttpd later I have it up and running - SSL support is built in, and it only took me five minutes to self-sign a certificate and get it going. FastCGI was just as easy. The first thing I noticed is how quickly the server starts up - that might not sound like an important feature, but in a development environment, where I tend to restart the server regularly (anybody knows of a better way to force a FastCGI application to reload, b.t.w?) it’s very nice to have. There was also a noticeable improvement in the speed of serving disk-based resources (the improvement in performance, according to the benchmarks is indeed quite impressive). What really bought me, though, was the configuration - Lighty’s configuration style is so intuitive, and after just a few minutes of playing with it I had the feeling that I know how to do most of what I wanted - there’s a uniform syntax for setting parameters or adding items to lists of parameters, and statements can always be qualified with a rule (only for a certain domain, or port, or matching an expression on the query, you-name-it).

Here, for example, is what my configuration looks like (with some comments):

# HTTPS support for the entire subdomain
# (note that the rule could be anything at all)
$SERVER["socket"] == "myapp.mydomain:443" {
  ssl.engine = "enable"
  ssl.pemfile = "/path/host.pem"
  ssl.ca-file = "/path/host.cert"
}

# Configuration for my application's subdomain
$HTTP["host"] == "myapp.mydomain" {
  # Add an alias to the filesystem path of my app code
  alias.url += ( "/the-app/" => "/path/to/app/code/" )

  # Set-up the FastCGI server
  fastcgi.server = ( "/the-app/app-script.fcgi" =>
   (( "socket" => "/tmp/fastcgi.socket",
      "bin-path" => "/path/to/app/code/app-script.fcgi",
      "max-procs" => 1
   ))
  )

  # Rewrite rules
  url.rewrite-once = (
    # Use Lighty to serve static resources
    # it's much faster that way!
    "^/(css|js|images)/(.*)$" => "/the-app/$1/$2",
   # Rewrite all other urls to be served by the application
   # So that I can construct pretty URLs
    "^/?(.*)$" => "/the-app/app-script.fcgi/$1"
  )
}

If you’ve ever had to configure Apache, you’ll immediately notice how much nicer Lighty’s format is, and with performance being as good as it is, I think I will now default to using Lighty whenever I can. If you need a good web server, give Lighty a try, you wont be disappointed!