Web Server

HTTP is a text protocol simple enough to implement in an afternoon and strict enough that the details matter. These chapters parse a request into a method, a target and headers, then put a socket in front of the parser and answer a real client. The parsing runs in this page; the server binds a port, so it runs on the build machine instead, and CI checks what the client received.

1. HTTP declares no length up front, so a server reads until it sees a blank line. That single rule is the whole framing problem.
2. Header names are case-insensitive. Comparing them exactly works against your own client and fails against somebody else's proxy.
3. A response without Content-Length leaves the client waiting, because nothing else tells it the body ended.
4. The parser never needs a socket. Taking bytes and returning a request is what lets the same code be tested, fuzzed, and run on a page with no network at all.

8 chapters.

• Parsing an HTTP RequestA request line, some headers, a blank line. The blank line is the hard part.
• An HTTP ServerThe parser from the last chapter, with a socket in front of it.
• Serving Files SafelyDecode first, then check. Doing it the other way round is the bug.
• Routing and Query StringsEverything after the question mark, and the dispatch table that ignores it.
• Form BodiesThe same encoding as a query string, arriving somewhere it can be much larger.
• Cookies and SessionsA cookie is a string the client stores and hands back. Everything else is policy.
• A Template EngineSubstitution is the easy half. Escaping by default is the half that matters.
• File UploadsA format where the client picks the delimiter, and the filename is a lie until proven otherwise.