I have seen the light

By: on December 12, 2006

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!

FacebookTwitterGoogle+

6 Comments

  1. matthew says:

    Actually, I find lighttpd’s fastcgi configuration quite confusing as soon as you’re doing anything non-standard, for example running multiple fastcgis within the same host is one of those endless “trial and error” configurations.

    Also, the documentation is pretty terrible: apache has much better documentation which is also much closer to being complete than lighttpd’s. The reverse http proxy in lighttpd is particularly awful, only supporting http 1.0 at the last check.

    Having said all that, I do use lighttpd because it’s lighter than apache and under 64-bit linux is pretty much the only choice for unencumbered fastcgi. Just for the record, the excellant “Pound” reverse http proxy is the best solution to that limitation of lighty, plus it can do SSL termination which is very useful.

  2. matthias says:

    FastCGI … Apache2 doesn’t really have any good solution

    Can you elaborate? All I had to do on my debian system was to install the libapache2-mod-fastcgi package and make some minor tweaks to the apache config.

  3. tom says:

    @matthias

    Apache2’s FastCGI support isn’t very good. One problem I’ve had with it is that it doesn’t report itself to be what it is, so applications that take advantage of a middleware layer must explicitly be told to behave as a FastCGI server (and can’t guess it for themselves). I heard other complaints about the correctness and quality of mod-fastcgi (but nothing I ran into myself).

  4. tom says:

    @matthew

    running multiple fastcgis within the same host is one of those endless “trial and error”

    Do you mean ‘running more than one FastCGI application on the same host’ or ‘running multiple instances of a FastCGI application on the same host’? If the former, that’s quite serious – care to elaborate? Otherwise, why would I care?

  5. matthew says:

    @tom

    Within the same:

    $HTTP["host"] == "blah" {
    }

    block, if you want to map urls to more than one separate fastcgi instance, the resulting configuration is not explained by the documentation and is fragile. Take the following working config snippet:

    $HTTP["host"] == "hikij.wellquite.org" {
        server.document-root = "/home/matthew/hikijInstall/web/"

        $HTTP["url"] == "/Wiki.hs" {
            fastcgi.server = (
                "/Wiki.hs" =>
                  ((
                    "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki.fcgi",
                    "socket" => "/tmp/hikij.fcgi.socket",
                    "check-local" => "disable",
                    "min-procs" => 1,
                    "max-procs" => 1,
                  ))
            )
        }

        $HTTP["url"] == "/private/Wiki.hs" {
            fastcgi.server = (
                "/private/Wiki.hs" =>
                  ((
                    "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki-toa-mft-ms.fcgi",
                    "socket" => "/tmp/hikij-toa-mft-ms.fcgi.socket",
                    "check-local" => "disable",
                    "min-procs" => 1,
                    "max-procs" => 1,
                  ))
            )
        }
    }

    Now if you look at the documentation there is absolutely no way you’d believe that was necessary. The closest from the docs is probably:

    fastcgi.server = ( ".php" =>
      (( "host" => "127.0.0.1",
         "port" => 1026,
         "bin-path" => "/usr/local/bin/php"
      )),
      ".php4" =>
      (( "host" => "127.0.0.1",
         "port" => 1026
      ))
    )

    Which, you might think, as it maps different extensions to different destinations, might be a suitable template. You would also, from that snipped, notice that “php” comes first and “php4″ second, so clearly in converting the extension to a regexp, it’s putting a $ at the end. In prefix form you might therefore expect that it puts a ^ at the start. It turns out that with enough thought, this snippet can be used as a template. For example:

        fastcgi.server = (
            "/private/Wiki.hs" =>
              ((
                "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki-toa-mft-ms.fcgi",
                "socket" => "/tmp/hikij-toa-mft-ms.fcgi.socket",
                "check-local" => "disable",
                "min-procs" => 1,
                "max-procs" => 1,
              )),

            "/Wiki.hs" =>
              ((
                "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki.fcgi",
                "socket" => "/tmp/hikij.fcgi.socket",
                "check-local" => "disable",
                "min-procs" => 1,
                "max-procs" => 1,
              ))
        )

    works fine. But reverse the order of the two stanzas and you’ll only ever hit the first. The problem is that extension in the documentation is nicely converted into a regexp with a $ at the end, anchoring it. But with the prefix form (i.e. starting it with a ‘/’), there is no ^ prefixed so you get unexpected matching going on. This would be ok, if it was documented suitably. The fact that their trac wiki contains endless wrong links and the documentation is poor and often out of date only emphasises how much of a mess apache is in given the popularity of lighttpd. From their wiki home page try actually finding the fastcgi documentation…

    @matthias

    The libapache2-mod-fastcgi package is non-free and does not exist for 64-bit linux. Thus should be discounted forever more.

  6. Tom Berger says:

    @matthew

    Interesting … at least now we know.

    I hear ya about the lack of documentation, but I’m hopefull – Lighty is a relatively young project, but it’s sponsored by a serious vendor and is quickly gaining adoption, so better documentation can’t be that far away.

Post a comment

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>