Gerrit Baum

I work from captured responses, so every claim here is about what a header does in practice rather than about what it was intended to mean. Status codes split into five classes and the classes carry meaning that the individual codes then refine. A redirect code tells the client to go elsewhere, and a client following one repeatedly is the signature of a loop. A client error means the request was wrong, and a server error means the request was fine and the response was not. Treating those two the same is how a retry policy gets built wrong. Caching is where the surprises concentrate. The cache directives compose, and the interaction between a response's freshness and an intermediary's existing copy is the part people model incorrectly. A shared cache will not store a response marked private, which matters because a page that varies by cookie needs a response that is explicitly shareable and a directive saying so. Conditional requests are the efficient half of caching and mostly unused. With an ETag or a last-modified time, the client can ask whether anything changed and be told it has not, and the answer costs a header rather than a body. Behind a CDN, most of the header decisions stop being yours, because the response headers the client sees are often a merge of what the origin sent and what the CDN added. Reading the chain rather than the origin is the only way to know what arrived. Every page here includes the response as sent, because the version that arrived is what arrived and it is rarely the version that was configured.