HTTP Status Code Lookup

Every code here cites RFC 9110 where RFC 9110 defines it. That matters more than it sounds: RFC 2616 was obsoleted in 2014, the RFC 7230–7235 series that replaced it was itself obsoleted in June 2022, and a reference still quoting 2616 is quoting a specification superseded twice.

401 and 403 are named backwards

401 Unauthorized actually means unauthenticated — no credentials, or bad ones — and it must carry a WWW-Authenticate header saying how to fix that. 403 Forbidden means you were identified and still may not do this, so retrying with the same credentials will never work. Where acknowledging a resource exists is itself a disclosure, 404 is the better answer than 403.

400 or 422

400 means the server could not parse the request — malformed JSON, a broken header. 422 means it parsed fine and then failed validation: well-formed, semantically wrong. The practical test is which layer rejected it, a parser or your own rules.

Caching is a property of the code

Several codes are heuristically cacheable by default under RFC 9110 §15.1, even with no Cache-Control at all — 200, 301, 404 and 410 among them. That is why a wrongly-served 301 is so hard to take back: it may be cached indefinitely by clients you will never reach. An explicit directive always wins, and this field describes the default in its absence.

418 is not real

It comes from the Hyper Text Coffee Pot Control Protocol, an April Fools RFC from 1998. It is kept as reserved in the IANA registry so nobody assigns 418 to anything — which is a different thing from being a code you should return.

429 should carry Retry-After; a client that ignores it and retries immediately is exactly the behaviour the code exists to signal. 503 with Retry-After is the correct response for planned maintenance — it stops a crawler treating the outage as removal. 451 takes its number from Fahrenheit 451.