Comment by Joker_vD

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