Nadia Farouk

I treat HTTP as a text protocol with a written grammar, and most surprises come from reading a summary rather than the specification. The request line, the header block and then an optional body, with the body delimited by length or by chunking rather than by a marker. Headers are case-insensitive, and their order carries no meaning.

Servers may combine repeated headers in ways clients do not expect, and this is where several bugs live: multiple values in one comma-separated line against several repeated lines are not the same thing to every implementation. Caching is the largest single source of surprise. Cache-Control exists in several forms, and max-age, no-cache and no-store are routinely confused.

no-cache means revalidate before use, not do not store, and that difference accounts for a large share of pages that appear not to update. ETag and Last-Modified exist so a client can revalidate cheaply, and a server that sends an ETag but ignores the conditional request forces a full transfer every time. Vary decides which request headers change the identity of the response, and a missing Vary on a page served differently by cookie produces a cache serving one visitor's content to another.

Status codes get misused more than any other part. Several codes are used as success with a body attached, which breaks clients that branch on the code, and a 302 on a request that should be a 307 changes the method. I close each page on what a browser sends, because the difference between a tool's headers panel and the request that went over the wire is where most of these explanations stop matching reality.