An HTTP/1.1 response starts with a line like 'HTTP/1.1 404 Not Found'. What happened to that trailing reason phrase in HTTP/2 and HTTP/3, and what breaks in software that depends on it?

## Where the phrase came from HTTP/1.x is a text protocol, and its response begins with a status line: the protocol version, a space, the three-digit code, a space, and a free-text **reason phrase** — `HTTP/1.1 503 Service Unavailable`. The phrase existed so a human reading a telnet session could see what happened. It was never part of the machine contract: the specification states that the phrase is advisory, that recipients SHOULD ignore it, and that a server MAY send an empty phrase. Nothing requires the phrase to match the registered text for the code, and nothing requires it to be present. ## What HTTP/2 and HTTP/3 did HTTP/2 replaced the text head with a binary, HPACK-compressed header block, and HTTP/3 did the same with QPACK. Both express the response head as header fields only, with control information carried in **pseudo-headers** that begin with a colon. For responses there is exactly one: `:status`, whose value is the three-digit code as a string. There is no version token and no reason phrase in the wire format — they were deliberately removed as redundant bytes that carried no protocol meaning. Header field names are also lowercase, and connection-specific fields (`Connection`, `Transfer-Encoding`, `Keep-Alive`, `Upgrade`) are forbidden. A client stack still has to present *something* to application code that expects `statusText`. Implementations diverge: browsers over h2 return an empty string for `Response.statusText`; some libraries look the code up in a static table and synthesize the canonical phrase; a proxy translating h2 to h1 for a legacy backend has to invent the phrase from that same table. In every case the value is manufactured locally, not received from the origin. ## What actually breaks - **Error detail smuggled into the phrase.** Frameworks let you do it — Java's `HttpServletResponse.sendError(400, "missing customer_id")` historically set the phrase, and hand-rolled servers write it directly. Over h2, or through any translating hop, the message evaporates. Support then debugs a bare `400` with no context. - **Assertions and log parsing.** Tests written as `expect(res.statusText).toBe('Not Found')` pass on an h1 dev server and fail behind an h2 edge. Log pipelines with a regex over the status line get empty or synthesized text, which quietly changes dashboards. - **Client branching on phrase text.** Any `if (statusText === ...)` is broken twice over: the phrase was never normative even in h1, and it is absent in h2/h3. - **Header injection defences.** CRLF injection into a reason phrase was a real response-splitting vector in h1; it simply has no analogue in h2/h3, which is one of the reasons the field was dropped. ## The design lesson The status code is the machine-readable contract — three digits, a class, registered semantics. Everything else belongs in the **response body**, in a structured format the client can parse: an error object with a stable machine code, a human message, and any field-level detail. `application/problem+json` is the standard shape for that. Headers are the second-best place for machine-readable signals (`Retry-After`, `WWW-Authenticate`), and they survive all HTTP versions. A useful diagnostic habit follows from this: when a bug report says "the error message disappeared in production", check whether production terminates HTTP/2 at the edge while development runs HTTP/1.1. The same code path, the same status, a phrase that exists in one environment and not the other, is a classic version-dependent ghost.