> I’m half joking, but if we can have HTTP 418 I’m a Teapot then there is enough room in the HTTP standard for the more useful HTTP 419 Never Gonna Give You Up error code.
Actually, there was a proposal to remove the 418 code formally, but in the end it was grandfathered in. Unfortunately, unless you have convinced a lot of people to allow 419, it would be not allowed anymore (even in a April Fools' RFC) according to the established protocol of IANA controlling the allocation of error codes, and IANA no longer allow "joke" allocations unless there was an RFC clarifying why that particular code must exists in a non-joking manner (see 451, in homage to Fahrenheit 451 but is the recommended code for a informed block). Even 418 was technically only reserved in such a way that allows it to be overridden in case that a good demonstration that 418 should be the code for that error.
The thing that really disappoints me is that 418 I'm a Teapot isn’t registered—instead it’s reserved as “(Unused)”: https://www.iana.org/assignments/http-status-codes/http-stat..., https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics.... As it stands, I suspect (as one that’s been involved in a couple and examined more back in 2013–2014) that most even vaguely recent HTTP libraries that have some kind of status code enum or constants defined take their data from the HTTP status codes registry, with a single exception for 418 I'm a Teapot.
As far as a 419 is concerned, I’d argue that 418 is already suitable anyway as a joke alternative to the more serious 429/503: “wp-admin.php? I’m not WordPress, I’m a teapot!” (Similar style to the joke about one cow warning another about the mad cow disease in the area, and the other responding that it’s not not worried because it’s a helicopter.)
418 is defined in HTCPCP, an _extension_ to HTTP. That's why I never understood why people use it in HTTP. So it makes sense that it's only reserved in HTTP.
IANA controls http codes only insofar as no one has told them to knock it off yet. There's no major interop risk from conflicting (200, 400, 500) codes in the way there is for other namespaces because the semantics are essentially contained only in the first digit.
Actually, there was a proposal to remove the 418 code formally, but in the end it was grandfathered in. Unfortunately, unless you have convinced a lot of people to allow 419, it would be not allowed anymore (even in a April Fools' RFC) according to the established protocol of IANA controlling the allocation of error codes, and IANA no longer allow "joke" allocations unless there was an RFC clarifying why that particular code must exists in a non-joking manner (see 451, in homage to Fahrenheit 451 but is the recommended code for a informed block). Even 418 was technically only reserved in such a way that allows it to be overridden in case that a good demonstration that 418 should be the code for that error.