In a web framework, what does it mean that a response has been committed, and what does commit freeze?
answer
- two states, one transition
- first bytes out, no way back
- overflow, explicit flush, or handler end
- status and headers frozen, body still open
- error stage can only truncate afterwards
basics
~20 sA response is committed once its first bytes reach the client. Commit freezes the status line and every header, cookies included; only body bytes may still be appended. Buffer overflow, an explicit flush or the handler ending triggers it.
solid answer
~40 sCommitted means the framework has handed the start of the response to the client: the status line and header block are on the wire and cannot be recalled. From that point the only thing a handler can still do is append more body bytes, or abort the connection. Three things commonly trigger commit: the write buffer overflowing, an explicit flush, and the framework writing the response out when the handler finishes. The practical consequence is that error handling loses its power after commit, because an error stage can no longer replace a `200` with a `500` — it can only truncate. That is why a post-commit header change is an error in some frameworks, a warning in others and a silent no-op in the rest, and why fallible work belongs before the first write.
go deeper
Learn the definition: committed means the first bytes are already on their way, so the status and headers are fixed. Set them before writing anything and the rule never bites you.
Name the three triggers - buffer overflow, explicit flush, end of handler - and explain what stays mutable afterwards. The buffer-overflow trigger is the one interviewers push on, because it depends on payload size.
Show that you know what commit does to error handling and to monitoring: failures after commit are logged as successes, so you need a separate metric and a completeness signal for streamed responses.
Frame it as a platform default: buffer sizes, where streaming is allowed, and how a shared error stage behaves when it finds a committed response are decisions worth making once for everyone rather than per service.
## Commit is a one-way transition Every framework response object lives in one of two states. **Uncommitted**: status, headers and cookies are mutable in-memory values, body writes are accumulating in a buffer, and nothing has reached the client. **Committed**: the status line and header block have been serialized and written out, and the response has become an append-only byte stream. The transition happens exactly once, it happens the moment the first bytes go out, and there is no way back. Everything confusing about response handling follows from that single fact. ## What triggers commit | Trigger | Who caused it | Predictable? | |---|---|---| | Write buffer fills up | The size of your body | No - depends on payload and buffer size | | Explicit flush | Your code, deliberately | Yes | | Handler finishes and the framework writes the response | The dispatch pipeline | Yes | | Redirect or error shortcut that writes immediately | A framework helper | Usually, but easy to forget | The first row is the one that produces surprises. A handler that behaves correctly against a short payload can commit halfway through a long one, with no code change and no obvious signal. An **explicit flush is simply a forced commit**: it asks for the response to start now, before the handler is done. ## What commit freezes Frozen at commit: - the **status code** and its reason text; - every **response header**, including content type, content length or the absence of one, and caching-related fields; - every **cookie**, because cookies are carried as `Set-Cookie` headers; - the **framing decision** — whether the response declares a length up front or is delimited some other way, which the framework must settle before the header block goes out. Still possible after commit: - appending more body bytes; - flushing again; - ending the response normally; - aborting the connection, which is the strongest remaining signal that something went wrong. ## Why this dominates error handling Most frameworks have an error stage that turns an escaped failure into a response: choose a status, render a message, send it. That stage works by *setting* status and headers, so it depends entirely on the response still being uncommitted. If the handler already committed while streaming a large payload, the error stage has nothing to set. The client has a success status in hand, then either a short read or a body that stops mid-structure. This produces a nasty operational property: the access log records the committed status, not the truth. A burst of failures can show up as `200`s. If you rely on status-code dashboards alone, the incident is invisible; you need a separate signal for responses that failed after commit. ## How frameworks report a late change Behaviour differs, and a candidate should say so rather than assert one rule: - some frameworks raise an error on a post-commit header or status change, which surfaces the bug immediately; - some log a warning and continue; - some discard the change in silence, which is the worst case for diagnosis. Many also expose a way to ask whether the response is already committed, which is how defensive error handling checks whether it may still produce a proper response or must abort instead. ## Designing around the commit point 1. **Do every fallible step before the first write.** Authorization, lookups, validation and any conversion that can fail belong ahead of body output, so a failure can still pick its own status. 2. **Keep ordinary responses uncommitted until the end.** If the whole body fits the buffer, commit happens once, at the end, with full information - that is the easiest mode to reason about. 3. **Treat streaming as a deliberate choice.** Once you flush early you have traded the ability to change your mind for a better time-to-first-byte, and you need an agreed way for the client to detect an incomplete response. 4. **Check the committed state in shared error handling.** A generic handler that blindly sets a status will either throw or do nothing at the worst possible moment. 5. **Return immediately after a redirect helper.** It typically commits, so anything after it is at best dead code and at worst a late-change error. The short version worth saying out loud in an interview: **commit is the point where the response stops being a plan and becomes bytes**, and everything except appending content must happen before it.
- Why is a committed response with a later failure worse than a failure before commit?Before commit the error stage can replace the whole response with a proper status and message. After commit the client already has a success status, so the only remaining signal is truncation or a dropped connection, and monitoring based on status codes records a success.
- How does an explicit flush differ from the commit that happens when a handler finishes?Only in timing and intent. A flush is a forced early commit that trades away the ability to change status or headers in exchange for sending the first bytes sooner. The end-of-handler commit happens with the full response known, so nothing is given up.
- What can a handler still do after the response is committed?Append body bytes, flush again, end the response, or abort the connection. It cannot change the status, add or modify any header or cookie, or hand the request back to an error stage that would produce a different response.
Committing is like handing over the envelope and the address label while you are still feeding pages into it. You can keep adding pages, but you cannot re-address it, and if you stop early the recipient gets a half letter in a correctly addressed envelope.
saying these in an interview costs you the question
- Thinks the response is only sent after the handler returns
- Believes an error handler can always replace a response with a 500
- Says a committed response can still have headers appended
- Assumes every framework raises an error on a late header change
- Treats an explicit flush as free with no loss of control
- Confuses commit with the connection closing