Response Object & Commit

## The message format decides the order An HTTP response is not a bag of fields that a server fills in any order it likes. On the wire it is a fixed sequence: 1. a **status line** carrying the protocol version and the status code; 2. a **header block**, one field per line, including every `Set-Cookie` the response carries; 3. a blank line; 4. the **body** bytes, if the response has any. A server writes those bytes in that order because that is how the receiver parses them: a client reads the status, reads headers until the blank line, and only then knows how to read the body. Nothing about that changes in later protocol versions; they encode the same three parts differently but still deliver metadata before content. So the rule "status and headers before body" is not a framework convention you could argue with. It is the shape of the message. ## What the framework does with your calls Most server-side web frameworks give a handler a **response object** with roughly three groups of operations: set the status code, set or add headers and cookies, and write body content. The first two groups mutate in-memory fields. The third appends to a **write buffer**. While the buffer still has room, nothing has been sent. Your status is a mutable field, your headers are a mutable map, and you may keep changing them. That is why code that sets a header *after* a small write usually appears to work, and why the bug it hides is so easy to miss. The response leaves that mutable state when it is **committed** — the moment the first bytes actually go to the client. Commit is triggered by any of: - the buffer filling up because the body is bigger than it, so the framework must drain it; - an explicit flush, which forces the commit whether or not the buffer is full; - the handler finishing normally, after which the framework writes status, headers and whatever the buffer holds; - a redirect or an error shortcut, which in many frameworks writes the response immediately. ## Why cookies are not special A cookie is delivered as a `Set-Cookie` response header. It is stored in the same header structure, serialized in the same block, and frozen at the same instant. A handler that writes a page and then decides to attach a session cookie is making a header change, with all the same timing risk as adding any other field. Frameworks that expose a dedicated cookie helper hide the header, not the constraint. ## What goes wrong when the order is reversed | What you do | Small body (fits the buffer) | Large body (overflows the buffer) | |---|---|---| | Set status, then write | Correct status sent | Correct status sent | | Write, then set status | Appears to work | Status change lost or an error raised | | Write, then add a cookie | Cookie is sent | Cookie silently never reaches the client | | Write, then flush, then set a header | Header change lost | Header change lost | The dangerous row is the one that depends on size. A handler that renders a short result in development and a long one in production changes behaviour without any code change. Frameworks differ in how loudly they complain: some raise an error on a post-commit header change, some log a warning, some discard it in silence. You cannot rely on being told. ## The habit that makes it a non-issue Do all fallible and all decision-making work before the first byte: - resolve authorization, look up data and validate input first, so a failure can still choose its own status; - compute the status, content type, caching-related headers and cookies while nothing has been written; - write the body last, ideally in one place; - treat a redirect helper as terminal — return immediately after calling it rather than writing more. Stated as a single rule: **decide the response, then produce it**. That ordering is free when the body is small and it is the only thing that works when the body is large, which is exactly why interviewers use it as a screening question.