HTTP Servers

What a server does between a socket and a response: accept, parse, build a request object, route, execute, serialize, write bytes. The part frameworks hide most completely.

Anatomy of an HTTP Server
▶ lab

The seven things every HTTP server does between a listening socket and the last byte written, whatever framework sits on top.

Q · What does an HTTP server actually do between a listening socket and the last byte of a response?
Accepting Connections

A connection is not a request. Listen, backlog, accept and file descriptors decide what happens to traffic before your code exists.

Q · What happens to a request between the client's TCP handshake and the first line of my server code?
Parsing HTTP

Turning a byte stream with no message boundaries into a request — and why the parser is a security component, not a formality.

Q · How does a stream of bytes become a request object, and what decisions does the parser make on my behalf?
Request and Response Objects

What `req` and `res` really are: a mutable view over a socket, with a body that has not been read and a response that has a point of no return.

Q · What is the `req` object my handler receives, and why does the response sometimes refuse to be changed?
Status Codes From the Server's Side

A status code is an operational signal: it decides who gets paged, what retries, and whether the number is counted against you.

Q · Which status code should this failure return, given that the code decides retries, alerts and blame?
Keep-Alive and Connection Reuse

Reusing a connection removes a handshake from every request — and introduces a timeout you must coordinate with every hop.

Q · What does reusing a connection actually save, and what new failure does it create?
Request Bodies and Streaming

A body is bytes arriving over time at a rate the client controls, which makes buffering a memory decision and limits a survival requirement.

Q · Should this body be buffered into memory or streamed, and what does either choice cost me under load?