I don't have much to say about this patch in particular, but I want to praise OpenBSD's httpd in general. I'm a hacker, not a systems administrator, and while I know how to set up Unix systems, I'm not an expert, nor do I have the time or inclination to become one. OpenBSD's httpd (and the other OpenBSD daemons for that matter) are distinct in that they have so few features, and are documented so well, that I can configure them and feel that I understand exactly the implications of my configuration. I trust that what I have built works. I have even read the code on occasion if I was unsure about something - it's short and simple, so it's perfectly feasible.
I have no illusions about OpenBSD's httpd being able to replace nginx or Apache in larger deployments, or that the latter cannot be configured to be just as safe and robust, but for the lone hacker or researcher who just needs a simple web server to serve static files or front FastCGI, OpenBSD's httpd is an excellent fit.
I use Bernstein publicfile myself. Not only is it likewise a simple static content HTTP(S) server, but the rewrites in the OpenBSD patch doco here are standard functionality (and have been all along, for the past nigh on two decades) in publicfile. The second rewrite rule, incorporating the virtual host name into the pathname, is actually the default behaviour of publicfile; and the first rewrite rule, making de an alias for ch, is done with a symbolic link in the filesystem in publicfile.
I think I looked at this before. I like a lot of djb's stuff. It doesn't support TLS though, right? So you'd have to put nginx or something in front if you wanted that?
These are UCSPI tools. To encrypt their traffic over the network, one simply runs them via a UCSPI-SSL toolset instead of running them via a UCSPI-TCP toolset.
The sharp-eyed, who have compared that manual with the Bernstein original, will have noted that mentioning UCSPI-SSL is one of the very doco modernizations that I did. (-:
I used lighttpd before OpenBSD's httpd, and while it is close, it still has far more features and configuration knobs. It's not just about whether things work by default (Apache usually does as well), but whether I fully understand what my configuration actually means, and what the server ends up doing.
I used to use thttpd, but it is showing its age a little due to lack of updates.
For example one ommission that bit me is the lack of native-support for the X-Forwarded-For header, making it hard to use behind a reverse proxy. At the time I last looked the most common-patch for this didn't support IPv6 addresses which was a real show-stopper. Of course this was back in 2011 so things might have changed:
The original author stopped accepting patches to thttpd back in 2004 though, unless something has changed recently it's a little hard to recommend it for general-purpose use. That's lead to divergence in features between a few distributions.
(I run maybe 30 websites on one box. I run each one under a different UID, with a dedicated instance of lighttpd for each site - then I use haproxy/apache as the front-end. In the past I used thttpd, because I wanted things to be minimal, but I realized that thttpd was too minimal.)
It's not about the lack of features. It's about the features that fit 90% of the use cases (sometimes 95%, sometimes 99%, etc), without the software being bloated.
I have no illusions about OpenBSD's httpd being able to replace nginx or Apache in larger deployments, or that the latter cannot be configured to be just as safe and robust, but for the lone hacker or researcher who just needs a simple web server to serve static files or front FastCGI, OpenBSD's httpd is an excellent fit.