Introducing OpenBSD's new httpd [pdf]

So... Apache was removed from base on Mar 14 2014 in favor of nginx, and nginx on Aug 27 2014 in favor of OpenBSD httpd.<p>For sysadmins who closely follow the &quot;recommended&quot; way, having to migrate the configurations of the http server twice within half a year must have been a frustrating experience.<p>Also, I wonder what &quot;removal from base&quot; means exactly - can you still install them (the OpenBSD-patched versions) from the ports collection or something like that?

I&#x27;ve been going through the code for the last half hour and I really hope this isn&#x27;t representative of what the OpenBSD group considers to be defensive C programming.<p>Stack allocated buffers, questionable logic and a generally terrible style as well as a complete lack of comments.<p>Don&#x27;t take my word for it, see for yourself:<p><a href="https://github.com/reyk/httpd/blob/master/httpd/server.c" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reyk&#x2F;httpd&#x2F;blob&#x2F;master&#x2F;httpd&#x2F;server.c</a><p>The &quot;new&quot; is a bit off too, the copyright runs 2006-2015.

Is there a technical reason why you would implement HTTPS in a HTTP server? If you ran a separate process on port 443 to terminate SSL connections, and then proxy that request to a HTTP server running locally, there would be better separation of concerns.<p>For example, this setup would mean that a security flaw in the HTTP server that allowed a user to read memory would not be able to read any private keys used in the HTTPS server.<p>I guess some downsides would be some extra latency while the request is proxied, and some extra memory overhead for the second process.<p>I&#x27;m interested in anyones thoughts on this.

I love these guys:<p><a href="https://github.com/reyk/httpd/blob/master/httpd/server_http.c#L802-L804" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reyk&#x2F;httpd&#x2F;blob&#x2F;master&#x2F;httpd&#x2F;server_http....</a>

Supports TLS using LibreSSL, serves static files and FastCGI.<p><a href="https://github.com/reyk/httpd/issues?q=label%3Afeaturitis+is%3Aclosed" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reyk&#x2F;httpd&#x2F;issues?q=label%3Afeaturitis+is...</a><p>featuritis tag in die bugtracker for currently denied features. Clearly aiming for as simple as possible while being useful.

Slides are available here : <a href="http://www.openbsd.org/papers/httpd-slides-asiabsdcon2015.pdf" rel="nofollow">http:&#x2F;&#x2F;www.openbsd.org&#x2F;papers&#x2F;httpd-slides-asiabsdcon2015.pd...</a>

If I may take this opportunity... Does anybody know what I&#x27;m supposed to put in &#x2F;etc&#x2F;ssl&#x2F;server.crt for SSL encryption? I have concatenated all six possible permutations of my own certificate ssl.crt, the intermediate certificate sub.class1.server.ca.pem and the root certificate ca.pem, but this gives me the error <i>The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)</i> (my Ubuntu Chrome gives me a green lock, though). Feel free to visit my blank site <a href="https://ezequiel-garzon.net" rel="nofollow">https:&#x2F;&#x2F;ezequiel-garzon.net</a><p>Thanks!

<i>FastCGI: The protocol provides the single and fast interface to serve dynamic content</i><p>That&#x27;s a bad choice in my opinion. Without reverse proxy functionality httpd can&#x27;t match the flexibility of nginx.

Surprised that nobody has mentioned ashd yet: <a href="http://www.dolda2000.com/~fredrik/ashd/" rel="nofollow">http:&#x2F;&#x2F;www.dolda2000.com&#x2F;~fredrik&#x2F;ashd&#x2F;</a>

Does anyone know if the FastCGI implementation is complete i.e. it supports FastCGI processes in all three roles; Responder, Authorizer and Filter? I&#x27;ve always wanted to use FastCGI more but most implementations (in Apache and Nginx at least) only support some of those roles (or require work arounds using server specific features; i.e. apache filters rather than FastCGI filters)

I read the config file format and I fell in love.<p>I really hope this gets the portable treatment.

[update - i read the back story elsewhere and the reason is less boneheaded than i had assumed. still, i think the community needs to focus on higher priority needs and gaps]<p>this is the sort of thing that makes me happy i&#x27;m no longer involved in the OpenBSD world. httpd &amp; previously smtpd are two replacements that (in my opinion) have little additive value beyond existing, community-adopted solutions (e.g. nginx and postfix), diluting effort where it is needed.<p>does the world need a new httpd? maybe. but the world needs other replacement software to be done first because it&#x27;ll have a greater impact.<p>for example, OpenBSD could invest time and effort in maturing static code analyzers to assist in code audits (especially of ports).<p>i suspect this new httpd was done less because it was needed and more because it could be done. that&#x27;s the attitude i disagree with.

OpenBSD seems to have caught a bad case of the &#x27;not invented here&#x27; sickness. If they didn&#x27;t like where nginx was going, why not just fork it and have a working web server with a known codebase? The forks would diverge but they could still grab fixes from nginx whenever they wanted to.

What would be the elegant way to implement websockets on the new openbsd arrangement? Would it be to use relayd instead of httpd? Or is websocketd suitable for the openbsd base?

Why do they even have an httpd in base? They like to say they&#x27;re smaller and simpler than FreeBSD, but FreeBSD doesn&#x27;t include a web server in base!

Did OpenBSD just standardize on an HTTP server they wrote in 2 weeks, has no tests, doesn&#x27;t fully implement the spec…and then brag about it?

any performance benchmarks in the wild?

Https authentication support for Subversion could be the killer feature.

Why use a name that&#x27;s already in use as a general descriptor? At least the other httpds have names that can be used to differentiate them: <a href="http://en.wikipedia.org/wiki/Httpd" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Httpd</a>

I&#x27;m amazed we still use configuration files like that. Why not have some capable programming language (python, javascript) handle the configuration? This would let one more naturally describe things, and will eventually reduce the possibility of obscure configuration commands that do one very specific thing, and hence lead to frustration when the user needs something slightly different. Using a programming language, one could even configure using callbacks, etc. and is much more flexible.