So there has always been a multiplicity of web server software for Unix/Linux.
It certainly feels like I have, at some point or another, played with all of them. And I keep coming back to apache, which I’ve been using since 1995, when I first became responsible for running a web server (“this site”:http://www.med.miami.edu/, if you care).
Incidentally: Holy crap, 14 years.
Anyway, as I stare around the unix landscape, I see four general-purpose web servers with some mind-share: apache, lighttpd, cherokee and nginx. Yes, there are others, but they are niche players, or they are not general purpose. So here’s my issues:
h2. “lighttpd”:http://www.lighttpd.net/
For the last couple of years I’ve run wiki.mallet-assembly.org on a box that was running lighttpd. And, honestly, I’ve not really had anything to complain about; it was stable, it was fast enough, etc. But if I wanted to run fastcgi programs as some user other than www-data (better for security), I had to run them as their own daemons. This isn’t the end of the world. What ultimately made me decide against it was that lighttpd has spent much of the last two years in perpetual rewrite mode.
h2. “cherokee”:http://cherokee-project.com/
I’ve been paying attention to Cherokee for the last year or so. It was looking like an interesting alternative to lighttpd. And then I tried it. Just as was always the case with the Netscape Enterprise Server/iPlanet software that I hated when I was at Dorado, the only documented interface for configuration was web-based. This isn’t the end of the world. But when it mysteriously “broke comments”:http://mischeathen.com/2009/01/good-news-bad-news.html for no discernable reason–and we’re using straight CGI, the simplest possible option for it–that got it the boot. And it’s error log? Useless.
h2. “nginx”:http://wiki.codemongers.com/Main
Nginx is great at what it does. Seriously. Couldn’t live without it. But really, it’s a proxy that happens to have also been taught how to speak FastCGI (and IMAP and SMTP and various other things–it really is great), and as a consequence it doesn’t so some important things like, well, CGI. I am using it for wiki.mallet-assembly.org right now, because it’s ultra-light and I’m running mediawiki under FastCGI there, so it all works out, but I’m probably going to move it to apache before too long because…well, who wants to have to keep track of two different packages.
h2. “apache”:http://httpd.apache.org/
Big. Complicated, with too many options to keep track of. One of the more annoying configuration syntaxes around (Fake html tags to denote sections? Really?). But dammit, it works, even when you ask it to take care of spawning fastcgi processes as another user. And it’s not *that* baroque. And even when it is (mod_rewrite, I’m looking at _you_), it’s still better documented than any of the other options. And most of the unix-oriented web software just pretty much assumes you’re going to be using it.
There’s really just not any competition.
Now don’t get me wrong–I would be disappointed if suddenly everyone abandoned all of their other systems. An Apache monoculture would benefit no one. To those working on the other systems, well, I’m gonna keep looking at them and seeing how they evolve. If nginx sprouted *simple* CGI support (none of this “write your own FastCGI server process that would proxy the CGI scripts” stuff), I would almost certainly move to that.
But for the moment, Apache it is.
