OpenBSD's httpd gets URL rewrite | Hacker News Reader

OpenBSD's httpd gets URL rewrite

marc.info

75 pointsnjn16 comments

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.

* http://jdebp.info./Softwares/djbwares/guide/httpd.html

* http://jdebp.info./Softwares/djbwares/

* http://cr.yp.to/publicfile.html

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.

* http://jdebp.info./FGA/UCSPI.html

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. (-:

This is something I rather like about Lighttpd over in the Linux world

I want to have a simple web server on my server at home to run a distro mirror and some other HTTP-centric things

I install lighttpd, and just dump all the files I want to serve in /var/www/localhost/htdocs

Start the daemon, bam, working. No messing about with htaccess or other things

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.

Apache or Nginx would give you the same experience with a default install. Path would vary between the 3 of course.

I use thttpd when I don't need Apache. It also allows chroot(). I occasionally resort to CGI with it.

https://acme.com/software/thttpd/

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:

https://blog.steve.fi/ipv6_and_thttpd.html

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

sthttpd is a maintained fork.

I do like thttpd too, but chroot() is no replacement for pledge().

Agreed, but not everybody is lucky enough to run their core systems on OpenBSD.

Some of us have to sling some Oracle for a living.

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.

This is a patch. It was sent to a mailing list for review. It has not been committed.

Also here's the revised patchset, which is more thorough and changes some config syntax:

https://marc.info/?l=openbsd-tech&m=152763303217829&w=2

https://marc.info/?l=openbsd-tech&m=152763343417988&w=2 (adds rewrite)

https://marc.info/?l=openbsd-tech&m=152763318517884&w=2

What I really like about this is how short, and readable, the patchset for the feature is.

Sure, it lacks tests - and it's had a couple revisions since… but it's something to behold.

I'm hopeful that someday httpd will support adding custom response headers -- for things such as adding a cache-control header.

Until then, it seems the recommendation is to run relayd in front of httpd, in order to add such headers.

Reply on news.ycombinator.com