What does a web framework send when a handler returns nothing, and how does it tell that from a handler that already wrote the response?

## No return value means no body model Return-value mapping exists to turn a value into bytes. When a handler returns nothing — the function has no result, or the framework observes an explicit empty result — there is no value to give a writer. The framework still has to finish the response, so it must decide what an empty result means. Two outcomes are common, and this is one of the places frameworks visibly disagree: - **A no-content status (`204`).** Read as: the request succeeded and there is deliberately no representation to send. The response carries no body, and `204` tells the client not to look for one. - **An empty success (`200`).** Read as: the request succeeded, and the body is simply zero bytes, framed with a zero length. Both are legal HTTP; they say different things to a client. A client that branches on the status sees a clear signal from the first and has to test the body length under the second. ## The second path: the handler already wrote the response A framework hands the handler access to the response as well as the request. A handler can bypass the whole mapping step: set the status, write headers, push bytes and return nothing. If the framework then also ran its empty-result mapping, it would either overwrite a status that was already sent or append a second body — so before mapping it checks a **handled/started signal** on the response. That signal is set when anything has been written or when the handler explicitly declares that it produced the response itself. When it is set, mapping is skipped entirely. (What can and cannot still change once bytes are on the wire is the response object's own concern.) ## The decision table | Handler behaviour | Mapping step | Typical result | |---|---|---| | Returns a value | serializes it | body plus a default success status | | Returns nothing, wrote nothing | nothing to serialize | empty response: `204` or empty `200`, framework-dependent | | Returns nothing, wrote the response itself | skipped | exactly what the handler wrote | | Returns a value *and* wrote the response | ambiguous | framework-dependent: the write may win, the value may be appended, or it may error | That last row is the interesting one and the reason the question gets asked. A handler that does both has stated two intentions, and no framework can honour both. ## Why the empty-response choice matters in practice - **Clients that parse unconditionally.** A client that always parses the body chokes on zero bytes. A `204` lets it skip parsing; an empty `200` does not announce itself. - **A body sent with a no-content status is a protocol error.** If you map to `204`, nothing may write a body afterwards — including a well-meaning later stage that wants to attach a message. - **Delete and update endpoints.** These are where handlers most often return nothing, and where clients most often disagree about whether to expect a payload. Which status such an endpoint *should* answer with is an API-design decision; what the framework does when you say nothing is the mechanism described here. - **Contract drift.** If half your no-return handlers land on `204` and half on empty `200` because some were written with a wrapper and some without, clients grow two code paths for the same shape. ## Making it explicit The fix is the same as everywhere in return mapping: **state the intent instead of inheriting a default**. 1. Return a wrapper that names the status you mean, even when the body is empty. It documents the endpoint and it survives a framework upgrade that changes the default. 2. Decide one convention for empty responses across the service and apply it to every handler that returns nothing. 3. Never mix writing the response directly with returning a value in the same handler; pick one style per handler, and prefer returning values because they are easier to test. ## What a good answer sounds like Say that no return value means no body model, that the framework therefore emits an empty response and that the exact status is a framework default — `204` or empty `200` — not something the language's empty result dictates. Then explain the handled/started check that lets a handler take the response over completely, and finish with the ambiguity of doing both. That covers the mechanism, the variation and the trap.