Node implements the 418 I'm a Teapot status code in a few places.

Its source is RFC2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Note the title - HTCPCP/1.0 is not HTTP/1.x.

HTCPCP was an April 1 joke by Larry to illustrate how people were abusing HTTP in various ways. Ironically, it's not being used to abuse HTTP itself -- people are implementing parts of HTCPCP in their HTTP stacks.

In particular, Node's support for the HTCPCP 418 I'm a Teapot status code has been used as an argument in the HTTP Working Group to preclude use of 418 in HTTP for real-world purposes.

While we have a number of spare 4xx HTTP status codes that are unregistered now, the semantics of HTTP are something that (hopefully) are going to last for a long time, so one day we may need this code point.

Please consider removing support for 418 from Node, since it's not a HTTP status code (even by its own definition). I know it's amusing, I know that a few people have knocked up implementations for fun, but it shouldn't pollute the core protocol; folks can extend Node easily enough if they want to play with non-standard semantics.

Thanks,

/cc @domenic @jasnell

@nodejs/http

"implementation" is defined loosely in this case given that Node.js doesn't do anything with it other than assign the default status message if it's used. We could deprecate the Teapot status message and easily reassign it later as a semver major. In the http2 implementation I can make sure it's not assigned a constant yet.

It looks like 418 is technically not registered with the IANA.

FWIW it seems Go supports 418 as well. Not sure about support anywhere else though.

A removal would be semver-major. I'm not sure we would want to add the overhead of checking explicitly for 418 to do a runtime deprecation.

Yeah, I'm thinking docs only deprecation in 9.x and EOL in 10.x

WFM, thanks. I'll chase Go.

I'm not sure this is really requesting a feature, per-se. I am largely indifferent, if we can do the change and people want it, sure?

Is there a reason for removing this now? It's a fun bit of trivia that adds flavor without harming anyone - it would be trivial to remove should an actual error 418 be added to HTTP (or should enough errors be added that it starts running out of numbers).

Is there a reason for removing this now

Yes. Given that changing it would require a full semver-major deprecation style, beginning the process of deprecating this now allows us to adopt any future real 418 status code much faster later on. We are already committed to keeping the I'm a teapot status in 8.x which will be supported for the next 32 months. If we wait any longer, we'll be committed to it also being included in 10.0 LTS which would push it out several more years after.

Please note that the suggested change here is not going to stop anybody from using 418 with HTCPCP semantics if they want to, it’s just going to remove Node’s default support for it.

Surprised it isn't posted here already, but... http://save418.com/

I'm just a bystander, but that's some pretty strong opposition. :)

@addaleax A joke isn't much fun if you tell it to yourself; removing 418 from Node won't stop me from implementing it myself, but it will remove a fun and quirky easter egg to stumble upon - which is what everyone is lamenting.

beginning the process of deprecating this now allows us to adopt any future real 418 status code much faster later on

And are there currently proposals that would mean 418 will have a legitimate purpose?

I realise that in the far, far future we may need to use this code, but removing a widely-known 20-year old easter egg just for the sake of cleanliness seems a bit unnecessary to me.

I'm the guy behind http://save418.com (https://github.com/WhataShane/save418). I, like many others, enjoy stumbling upon (almost entirely) innocuous gags like 418. It's the sort of thing that'll put a smile on your face even when you're pressed to meet a project deadline and your boss is yapping at you one office over. It'd be a real shame to see it go.

To quote @romellem from the Go thread, who quite eloquently sums up the argument for 418:

Just to be clear, is your argument that when/if the 400 block runs out, we'll want that one extra code available to stretch out the usefulness of the 400 block just a bit further?

Unless I'm reading it incorrectly, the 400 block of HTTP status codes has more than 50 codes available. With the available "space" of the 400 block at more than 50%, this might be a pre-mature optimization for a problem that may never occur (400 block running out of available codes, that is).

Not trying to sound harsh, but I for one like fun little easter eggs that you find throughout a programming career. To me, it shows that everything that goes on to make a computer actually do work is still made by humans, and keeping small slices of that human element is nice (in my opinion). Your argument is sound and logical, but this requested change ever so slightly lowers the "fun-ness" of Go (and potentially NodeJS) in the spirit of engineering robustness. At the end of the day, I have to say I don't think that tradeoff is worth it.

(I appreciate the history lesson though! I always thought 418 was a part of the HTTP/1.x spec; didn't know about the "HTCPCP/1.0" spec. 🙂)

are there currently proposals that would mean 418 will have a legitimate purpose

Yes. There is a proposal for a new 4xx status code being discussed. Since 418 is not officially registered, it (in theory) should be used for the new code, but doesn't necessarily have to be... It's just not something that is up to us at all.

The thread is here if anybody is interested.

As someone who was involved in implementing rfc2549 for the IDF (NOT!), I'm +1 on precluding 418 from HTTP, hence IMHO it should stay in node. (until decided otherwise by the IETF or IANA)

@refack - IANA doesn't register it, and the IETF doesn't recognise it (the defining RFC is a joke RFC). So are you saying you support removing it, or not? confused

As mentioned, there are still over 50 HTTP codes left in the 400 range, I do doubt this will be a problem any time in the near future. Please do not kill fun things for such a small reason, remember that we are not computers ourselves.

@max213 As explained, this will be a problem in the future -- if HTTP lasts as long as we hope about it. Fixing it then will be MUCH harder than fixing it now (see the resistance we're already encountering and magnify it considerably).

HTTP status codes are defined by the IANA registry. If we have implementations claiming status codes outside of it, it's bad; node is NOT implementing HTTP here. Please respect the protocol.

@refack - IANA doesn't register it, and the IETF doesn't recognise it (the defining RFC is a joke RFC). So are you saying you support removing it, or not? confused

I'm saying until it is registered for anything else IMHO is should stay.
If you or IANA decide to accept the status quo, that would be cute. I'm kinda assuming that there are other codes which are even less frequently used.

P.S. I live next to a bridge whose length is "364.4 SMOOTS + 1 EAR" and it leads to the W3C offices.

P.P.S. Being the only person who is also a unit of length, Smooth grow up to be the chairman of ANSI and later the president of ISO.

I'm saying until it is registered for anything else IMHO is should stay.

The problem is that its inclusion in implementations like Node is being used to argue against the code being used for other (real) purposes.

Even if if it is, there are 50+ other vacant spots that are already open. Why does 418 have to be replaced with a "real" error code when we're nowhere near filling all the other 4XXs up?

I'm saying until it is registered for anything else IMHO is should stay.

The problem is that its inclusion in implementations like Node is being used to argue against the code being used for other (real) purposes.

I get that... But, well, the internet is a big ball of mud (Except of the amazing work done by the IETF) see https://bz.apache.org/bugzilla/show_bug.cgi?id=61383

_{I only represent myself, and won't block if there's momentum to deprecate 418}

@mnot I don't understand why this is an issue. If there is ever a sudden influx of new HTTP status codes then honestly you can just put another 0 on the end and we can have 1000 status codes. Also you're assuming HTTP 3 will still use status codes, it could use hash codes or tuples or anything honestly.

This is an issue that is so far in the future it's not worth acting on because we don't know what the landscape will be like.

Also 418 has uses in real production applications, see https://developer.amazon.com/dash-replenishment-service for an example.

The problem is that its inclusion in implementations like Node is being used to argue against the code being used for other (real) purposes.

Its adoption by the HTTP community at large is used to argue against it being used for other purposes? That seems fair enough to me - I would imagine that is roughly how any other code would be accepted into the protocol if it didn't originate there (e.g. nginx's 444). It would probably be preferable to argue for its inclusion in the protocol, but given its nature I think it is reasonable to simply avoid using its code before necesarry.