HTTP status codes — every code, what it means, and the RFC it comes from

RFC 9110, HTTP Semantics, published June 2022. It replaced RFC 7230 through 7235, which had themselves replaced RFC 2616 back in 2014, and it is where the status code registry now points for the core codes. It also absorbed three codes that used to live elsewhere: 308 came from RFC 7538, 421 from RFC 7540 (HTTP/2), and 422 from WebDAV’s RFC 4918, renamed from “Unprocessable Entity” to “Unprocessable Content”. Not everything moved, though, which is why this table cites per code rather than putting one RFC in a footer: 429 is RFC 6585, 451 is RFC 7725, and 423, 424 and 507 are still RFC 4918.

It is a real registration and not a real status. It comes from RFC 2324, the Hyper Text Coffee Pot Control Protocol, published on 1 April 1998 as a joke. RFC 9110 lists 418 as “(Unused)” and IANA keeps it reserved specifically so it can never be assigned to something serious. So you can look it up and you should not return it: no proxy, cache or client library has any defined behaviour for it, and “our API answers 418” is a support ticket waiting to be filed.

Two independent questions. Permanence: 301 and 308 say the resource has moved for good and caches and search engines should update; 302, 303 and 307 say it is temporary and the original URI stays canonical. Method: 307 and 308 require the method and body to be preserved exactly, 303 always turns the follow-up into a GET, and 301 and 302 sit in the middle — for historical reasons a user agent is permitted to rewrite POST to GET, and in practice they do. So a permanently moved API endpoint wants 308, not 301; a temporarily moved one wants 307; and the redirect after a successful form POST wants 303, so that pressing refresh reloads the result page instead of re-submitting the form.

401 means unauthenticated, despite being named “Unauthorized”. It says the request carried no valid credentials and the response must include a WWW-Authenticate header naming a scheme the client can try — sending different credentials might work. 403 means authenticated and still refused: the server understood who you are and will not do it, so retrying with other credentials will not help. The everyday test is whether logging in as someone else could change the answer. There is also a legitimate third option: a server is explicitly allowed to answer 404 instead of 403 when admitting the resource exists would itself leak something.

410 when you are certain it is gone for good and there is no forwarding address; 404 when you are not, or when you simply do not know. 410 is the stronger statement — “this was here, it has been removed, stop asking” — and crawlers treat it as more decisive than a 404, which they will re-check for a while in case it was a mistake. The practical difference is small enough that it is not worth agonising over: both remove a page from a search index eventually, and neither is a substitute for a 301 to the page that replaced it.

A Retry-After header, and a body that explains the limit. Retry-After takes either a number of seconds or an HTTP-date, and without it the client is left guessing — which in practice means retrying immediately and making your overload worse. RFC 6585 defines the code and recommends the body describe the limit; the widely used RateLimit header fields for the remaining quota are a separate, later specification and are not part of it. Note also that 429 is about the client’s rate, while 503 is about your capacity: use 503 with Retry-After when everyone is affected.

Because neither comes from your application — both come from something in front of it. 502 Bad Gateway means the reverse proxy reached your service and got back something it could not parse as an HTTP response, which usually means the process crashed mid-request or nothing is listening on the port the proxy is configured for. 504 Gateway Timeout means the proxy connected fine and gave up waiting, so your code is running and simply slow. That distinction is the fastest triage available: 502 points at the process, 504 points at a query.

Because they are not HTTP status codes in the standards sense at all — they are Cloudflare’s own numbers in the 520–527 range, returned by its edge to tell you which leg of the connection to your origin failed. 521 means your server refused the connection, 522 means the TCP handshake timed out (usually a firewall dropping Cloudflare’s IP ranges silently), 524 means the connection worked and your server did not finish in time, and 525 and 526 are TLS problems between the edge and the origin. Mixing them into the IANA table would make this page lie about the one thing it is for. The same applies to nginx’s 444 and 499, which never travel over the wire at all — nginx writes them into its own access log to record how a connection ended.

No. The whole registry is part of the JavaScript this page already loaded, so both the search and the lookup are running over an array in memory. There is no API call behind them, nothing is written to localStorage, and the page keeps working with the network switched off.