We are hiring

I have seen the light

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):

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!

6 Comments

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.

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).

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?

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:

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.

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.