Which HTTP status codes are defined to carry no response content, and what goes wrong on the wire if a server writes body bytes with a 204 No Content or 304 Not Modified?

## Which responses have no content HTTP distinguishes what a status code *means* from how a message is *framed*. Four situations produce a message with no content at all: 1. **Any 1xx interim response.** An interim ends at the end of its header section by definition. 2. **204 No Content.** The request succeeded and the server intentionally has nothing to return. Header fields may still carry useful metadata (`ETag`, cache headers, pointers). 3. **205 Reset Content.** Like 204, plus a request that the user agent reset the document view that caused the request — historically "clear the form so the operator can type the next record". It is rare in modern APIs. 4. **304 Not Modified.** The client's cached representation is still valid, so sending the bytes again would defeat the purpose. A 304 may echo header fields that would have appeared on the 200 (validators, cache directives, `Vary`), but transmits no content. Two further cases are about the request, not the code: a response to **HEAD** never has content whatever its status, and a successful response to **CONNECT** switches the connection to tunnelling. ## Why the framing matters HTTP/1.1 is a byte stream over a reused connection. The parser must know exactly where one message ends and the next begins. Normally that comes from `Transfer-Encoding: chunked` or `Content-Length`. For the bodiless codes the rule is stronger: the recipient knows the message ends at the header section and does **not** treat a `Content-Length` as a promise of bytes to come. So when a buggy server emits a `204 No Content` with `Content-Length: 5` followed by five bytes, the peer has already finished the response at the blank line. Those five bytes are now interpreted as the first bytes of the *next* response. On a persistent, pipelined or proxied connection that means one client can receive another client's data, or an attacker can plant a synthetic response — the class of bug known as response splitting or desynchronization. This is why frameworks and reverse proxies aggressively strip content written alongside a 204, and why intermediaries may drop a `Content-Length` on these codes. HTTP/2 and HTTP/3 are safer here because framing is explicit: content lives in DATA frames and a bodiless response simply ends the stream with END_STREAM on HEADERS. Sending DATA anyway is a protocol error on that stream rather than a corruption of everything after it — but the semantics are identical, and an intermediary translating h2 to h1 can reintroduce the h1 hazard. ## 204 versus 200 with an empty body Both are legal. `200 OK` with `Content-Length: 0` says "here is the representation, and it happens to be empty"; `204` says "there is no representation to send at all". Both are defined as cacheable by default, so the difference is semantic, not a caching trick. The practical divide is client behaviour: many HTTP clients and browser `fetch` wrappers will try to parse an empty 200 body as JSON and throw, while 204 is handled as a distinct no-content case. And `205` should never be used as "204 but fancier" — it carries a real instruction to reset the view, which almost no API client implements. ## How this shows up Symptoms of getting it wrong: a proxy logging "invalid response" after a delete endpoint, intermittent cross-response corruption under keep-alive, a client that hangs waiting for a body that a `Content-Length` promised, or a JSON parser error on a successful DELETE. The fix is always the same — pick the code whose framing matches what you are actually sending, and let the framework, not application code, own the length headers.