[taftster]

Sneakily hard, actually. There's different versions of HTTP (of course), so pick your target. But when you hit HTTP/2.0, it's not a simple request/reply model (if HTTP/1.1 can be described as such). The intermixing of various client headers and what they imply to server behavior, handling of the streams and when to open vs. when to close, http/2 multiplexing, etc. Don't forget HTTP/3 which uses the QUIC protocol (UDP based) instead of TCP.

Interestingly though, a trivial HTTP server is actually very easy to implement as well. A very crude HTTP/1.0 server (or maybe even a limited scope HTTP/1.1 server) can actually make for a fun afternoon project. Like minimal (or no) concurrency support, all TCP connections closed after the request/response cycle, GET only (or maybe POST only), etc.

So it's a mixed bag of what you want and how you define an HTTP server.

[astrange]

I can't think of a good reason to want to implement the complex parts. Write an HTTP service if you must, but make it HTTP/1.0 (or 1.1 for keepalive) and stick it behind nginx to do the newer versions and SSL termination.

(I also think all HTTP services should if possible be written in a shared-nothing CGI type language, and not embedded in your random stateful program. This way you can't accidentally leak info across user sessions.)

[taftster]

Both of these are great points. I do really appreciate an nginx (or other load balancer) front end. Or even cloudflare or whatever AWS/Azure offers. A simple horizontally scalable HTTP/1.1 backend with a reverse-proxy that can uplift your app is a great strategy.

Also, your comment about "shared-nothing" is interesting too. It surely doesn't hurt to think about it in this way, but likewise, might be out of scope for a simple web server concept (for example, if you're not even really supporting sessions at all).