Introducing OpenBSD's httpd [pdf] | Hacker News Reader

Introducing OpenBSD's httpd [pdf]

openbsd.org

50 pointstosh30 comments

Color me old and skeptical about "simple," "lightweight" web servers. Does anyone else remember when nginx was touted as the "lightweight" replacement for Apache because Apache was often "overkill"? (e.g. http://arstechnica.com/business/2011/11/a-faster-web-server-... )

Now it's this new httpd that is lighter than bloated nginx.

So, maybe nginx and apache and all the other webservers out there are too big and bloated and sloppy, despite being written by smart people and used to deliver many many performant websites. That's possible.

But it is also possible that, because programmers love to start from scratch and reinvent the wheel rather than reading and understanding other people's code and rather than researching other domains, they tend to create weak web servers and tout them as "lightweight" until eventually they either die or evolve to be useful to people who actually understand the nuances of serving resources over the web, at which point they get accused of "featuritis" and the cycle repeats.

At least for now they seem to be very fixed on just providing a very basic server and not trying to cover as many use cases. (see their bugtracker for what counts as "featuritis": https://github.com/reyk/httpd/issues?q=label%3Afeaturitis )

> I add the label "featuritis" to remind us of extra features (eg. ldap) that we reject now but might want to reinspect later.

That sounds absolutely reasonable and like a good policy.

I'm excited. This is perfect for 98% of people. And apache and nginx are always available for the 2% of people that need to do something more complicated.

Confs look familiar, and it's lightweight and will be secure. Perfect.

But no HTTP2.

I sincerely doubt HTTP2 qualifies as featuritis.

It's young; not expected to be base until this fall. Give it a few months and you'll see it in there.

The corresponding paper was posted recently, and there were a lot of comments: https://news.ycombinator.com/item?id=9202039

If you're never going to use this, it's a nice reading anyway. Goes over their major concerns, their problems with other companies/OSS groups and the design of their solution.

I had hoped that an effort to replace nginx would use Rust and support HTTP/2.

It will when you write one and focus on your priorities.

For this httpd, it seems like the problem they were solving is that they needed an httpd, and the result is about what I'd expect from the OpenBSD folks.

Rust doesn't support anywhere near the number of platforms OpenBSD does, and has portions written under the Apache 2 license, which has terms that the OpenBSD team disagree with. So the chances of any Rust code ending up in OpenBSD anytime soon are slim to none.

Correction: all of the Rust compiler is dual-licensed under both MIT and Apache 2. If you distribute the Rust compiler yourself, this means that you can pick one license or the other or both. You can also retroactively defer the choice of license until a legal challenge appears, at which point you can collapse the license superposition to your liking. This is the whole point of dual-licensing!

Design and implementation starts at page 9.

I don't know OpenBSD's history vis-a-vis webservers, and these slides aren't clear about why they needed to build their own.

As a random guess, is it because Apache focuses on features, nginx on speed, and OpenBSD wanted a focus on security?

Apache:

OpenBSD was stuck on Apache 1.3 for ages because the license changes for Apache 2.0+ was incompatible. They also ended up maintaining their own fork for quite a while because patches to improve security were not being accepted upstream (I think)

Nginx:

License is fine, but it's getting feature bloat and the local patchset was getting unwieldy.

Conclusion: roll your own httpd that way you don't have to deal with this anymore.

Not really following OpenBSD, I didn't realize they considered Apache 2 license unacceptable til reading the above. For anyone else curious about the initial discussion of this, it took me some browsing to find http://marc.info/?l=openbsd-misc&m=107714762916291&w=2 (2004)

> The situation of nginx in OpenBSD frustrated me

What situation?

"It wasn't invented here."

Possibly (dunno). But they refer to that on slide 7:

    -  We also introduced new safer APIs like reallocarray()
    -  I wrote a big diff for nginx to adopt reallocarray() other such techniques
    -  And it got rejected.

Is reallocarray() BSD-specific? That might explain it.

It's OpenBSD specific. But it's also just 10 lines of portable C that are permissively licensed and can be added to any project without problems. It's even in a separate source file for this very purpose [1]

[1] https://github.com/robertbachmann/openbsd-libc/blob/master/s...

I like that. I might even swipe it for my own projects.

Don't know why you are being downvoted, that is a huge amount of the motivation behind openbsds innovations.

you're both being downvoted because you're both completely wrong. it turns out permissively licensed, security-focused, and easy to maintain code bases aren't easy to find outside of OpenBSD. so sometimes they have to write their own.

say, a packet filter, for example...

did you even RTFA? They wanted to continue using nginx.

Exactly, they want to appropriate it and improve it in line with their philospohy. That isn't incompatible with my comment.

That would be forking, no?

They're not appropriating it. They're just creating another reverse proxy.

That'd be true if it weren't for a bunch of external projects that OpenBSD uses or which are hosted as part of OBSD but weren't invented by the OpenBSD folks (tmux is one such example). It all boils down to priorities: if your priority is security, chances are there's very little code out there you can drop in and use.

See https://news.ycombinator.com/item?id=9202522

...did you just skip to slide 8? Explaining that was the first 7 slides.

- They need a web-server in base.

- They demand security.

- He submitted a patch for nginx to embrace new secure methods.

- It was rejected.

- Because a base server is required in base, and they don't want to maintain a fork of nginx for base: "Introducing HTTPD".

Reply on news.ycombinator.com