Doesn't seem to be up =\

I would expect GitHub page. The server seems down

Consider it broke. You are getting hugged to death by HN. Throw Cloudlfare in front.

Should be back up now with a very temporary workaround in place.

You are lucky that all of your sample files have dots in their names. (-:

        if (!result) result = std::strchr(s, '\0');

Are you near Sydney? I noted a possible link to the Central Coast. I will contribute a smaller device if you're game to host it.

PS. You may be unaware that your shortened domain name 'benren' from your whois-available real name means "stupid person" in Mandarin. Only noted because there is a company registered with the same name since 1999. On the off chance it's yours, probably not the best marketing in a global world. Just throwing it out there.

I saw the title, and this is everything I have ever hoped for.

Nice effort but this isn’t interesting at all. You skipped the most interesting part; parsing http. This is beejs networking tutorial with writing a file to a socket.

Harsh? Maybe, but you’re posting this to a site with some of the most talented developers on planet. Real talk, sorry.

I've got a similar one, but with http 1.0 and partial 1.1 support, multi threaded, etc. in C

https://GitHub.com/lionkor/http

If you want to make it actually decently safe, one approach would be to make a list of all the syscalls you critically need after you have loaded all the content in memory (strace can help), then write a seccomp filter to block all the others. Since you don’t need filesystem interaction or pretty much anything except socket I/O, your syscall allowlist can be pretty short. This will ensure that even if an attacker manages to exploit a bug (like a UAF) they’ll be dropped into a sandbox with very little useful functionality.

Reminds me of Jef Poskanzer’s micro_http: https://acme.com/software/micro_httpd/

Easiest way to make it safe is

1) Run it in a container

2) Isolate it through a reverse proxy, probably nginx

Good to see more tiny / small http servers. I'm not a fan of sticking Nginx in a container which maybe bigger than the assets its serving. A statically compiled httpd from busybox has been great for this reason but its good to see more options.

This should be a rite of passage: Read a sizeable RFC and make a passable implementation.

    // it doesn't seem to love piping or redirecting output without this, even
    // with the newlines above
    fflush(stdout);

Ah, the full buffering mode. I believe it can be fixed by calling

    setvbuf(stdout, NULL, _IOLBF, BUFSIZ);

once at the start.

On the whole, it actually almost implements the minimally required amount of HTTP/1.1: I would suggest adding support for HEAD requests, it's just a single flag that you need to set in the try_parse_request_path(), and check in generate_response(). Also, probably check that the request path is followed by "HTTP/1." before sending the response? And I'd really recommend finishing reading out all of the request from the socket (that is, until you've seen "\r\n\r\n"), or you may run into the problem of your clients not being sent the complete response [0].

But other than that, yeah, it is an HTTP server. The HTTP protocol is decently well thought out so that you can be oblivious of most of the features you don't want to support.

[0] https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-... — the tl;dr is that if you do close() on a socket that still has the data from the client you haven't recv()d, the client will be sent an RST.

> RFC 9112 is a fantastic document that details the exact format of HTTP 1.1 requests, how servers should respond to those requests ...

> This server follows almost none of that.

This made me chuckle :-)

I also have a tiny one, used in production with custom decompression and decryption for some IoT devices in the field, which push sensor updates to it. http 1.0 PUT only, multi-threaded and super efficient. One page only (about 50 lines or so). Pretty safe.