Chapter Two · HTTP Done Properly
HTTP Done Properly
HTTP is not the transport under Stagedoor's API; it is the contract every client, proxy, cache and retry loop reads before a handler runs. Six topics take the pieces of that contract one at a time: what a method promises about being repeated, what a status code instructs the client to do next, the six headers a service must own, what a cookie's attributes defend against, what a connection costs before the request exists, and how a validator turns 2,600 seat maps a second into 2,600 comparisons.
Marek reads Stagedoor's API the way a retrying client reads it, and finds four places where the service said one thing and meant another. POST /holds was called twice on a slow network and created two holds, because the method promised nothing and the client took it at its word. The scanner endpoint answered 200 with an error in the body, so the scanner's library, a venue Wi-Fi cache and the door itself all read success. The session cookie went out without SameSite or Secure for a year before a security review noticed. And the seat map was re-sent in full 2,600 times a second at on-sale, because no response carried an ETag and no client could ask whether anything had changed.
None of the four was a bug in a handler. Each was a promise the protocol makes on the service's behalf, and the service had not read the promise. This chapter reads them: methods as retry promises, status codes as instructions, headers as decisions, cookie attributes as threats answered, connections as the latency nobody's code accounts for, and conditional requests as the version column of Chapter 6 wearing an HTTP header. The chapter closes none of the three wounds from Chapter 1 on its own. It explains the double charge from the client's side, shows why the retried POST was correct behaviour, and fixes the contracts that the repairs of Chapters 6 through 10 depend on.
The reference for everything here is RFC 9110, and the book cites it where the text of the standard is the argument. What the chapter adds is the consequence: which layer acts on each rule, what it does when the service breaks it, and the number attached to each one at Stagedoor's scale.