The HTTP status codes 400 Bad Request and 422 Unprocessable Content are both client errors. What does each one mean per the HTTP specifications, and how do generic caches, proxies and clients treat them on the wire?

## The class both codes belong to HTTP status codes are grouped by their first digit. The 4xx class means *client error*: the server believes the fault lies in the request as sent, not in itself. RFC 9110 — the current core HTTP semantics specification, published 2022 — says a server sending a 4xx SHOULD include a representation explaining the error, and that repeating the identical request is not expected to help. 400 and 422 are both members of that class. Everything below is about *which* client error each one names. ## 400 Bad Request — "I could not parse or accept the message itself" RFC 9110 §15.5.1 defines 400 as: the server cannot or will not process the request "due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)." Three consequences follow from that wording. First, it is about the **message**, not about what the message asks for: a bad request line, a header field that violates field syntax, a `Content-Length` that disagrees with the body, a body that claims to be JSON and is not, a query parameter declared as an integer that arrives as `abc`. Second, it can be emitted **before the server understands the request at all**. You do not need to route to an application handler to know the message is broken. In HTTP/1.1, a framing error leaves the connection in an unrecoverable state, so RFC 9112 requires the server to close the connection after responding — which is why proxy-generated 400s so often carry `Connection: close`. In HTTP/2 and HTTP/3, a genuinely malformed frame is a protocol-level stream or connection error (`RST_STREAM` with `PROTOCOL_ERROR`) rather than a 400 status at all. Third, 400 is the **catch-all** of the class. RFC 9110 tells clients they must understand the *class* of a status code even when the specific code is unknown, and treat an unrecognized 4xx as equivalent to 400. So 400 is simultaneously a specific code and the default meaning of every 4xx a client has never heard of — including 422, to an old enough client. ## 422 Unprocessable Content — "I parsed it; the instructions don't work" 422 started outside core HTTP. WebDAV (RFC 2518, later RFC 4918) needed a code for a request body that was well-formed XML, of an understood content type, but contained instructions the server could not carry out. It was called *Unprocessable Entity*. RFC 9110 promoted it into core HTTP semantics and renamed the reason phrase to **Unprocessable Content** — same code, same meaning, modern wording. Its definition carries three preconditions: the server understood the **media type** of the content (which is why 415 Unsupported Media Type would be the wrong answer), the **syntax** of the content was correct (which is why 400 would be the wrong answer on syntax grounds), and the server was nevertheless **unable to process the contained instructions**. That last clause is the entire code. 422 is a statement about semantics: the request said something the server understood but cannot act on. ## Where the definitional line sits The line is *understanding* versus *acting*. 400 says the server never got far enough to understand what was asked. 422 says it understood exactly what was asked and could not do it. Note that the spec draws this line over the message and its content — it says nothing about business rules, validation frameworks, or which code an API contract should choose for a failed domain check; that selection is a contract-design decision owned by REST status-code selection, not by the wire specification. ## Wire-level facts that hold regardless **Neither is auto-retryable.** Unlike 429 or 503, neither code has retry semantics attached and neither has a conventional `Retry-After`. A generic client that resends identical bytes gets an identical answer. Retry is only meaningful after the request itself changes. **Neither is cacheable by default.** RFC 9111 lists the status codes a cache may store and reuse heuristically without explicit freshness information: 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, 501. 400 and 422 are absent. A shared cache reuses either one only when the response carries explicit freshness (`Cache-Control: max-age=…`, `Expires`), which almost nothing does. In practice both are one-shot responses. **Their origins differ.** 400 is routinely generated by an intermediary — reverse proxy, load balancer, WAF — for an oversized header block, a bad request line, or a framing violation, so the origin application never sees the request. 422 essentially never comes from an intermediary: producing it requires having understood the media type and inspected the content, which only the application does. That asymmetry is a real debugging tool — a 400 whose body is nginx HTML with `Connection: close` was rejected at the edge; a 400 in your own JSON envelope was rejected by your code. **Neither code carries machine-readable detail by itself.** The status line is three digits; anything a client can branch on lives in the body, for which `application/problem+json` (RFC 9457) is the standard shape.