-
Notifications
You must be signed in to change notification settings - Fork 28.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
418 I'm A Teapot #14644
Comments
@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). |
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 |
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. |
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:
|
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 |
@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. |
I'm saying until it is registered for anything else IMHO is should stay. 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. |
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 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. |
I don't think the 418 code is doing any harm whatsoever. Leave it alone. Ripping it out is a pointless waste of everyone's time. It might not be part of any official standards, but it's an accepted part of internet history. And unless you're going to go through every language, and every framework, and every HTTP library that's ever been written and create a PR for them - assuming you even have that option - removing it from a subset of them will cause more confusion and problems. @jdmansour I disagree that it's harmful to register 418 officially for these reasons. We should have learned from the development of the XHTML spec as compared to HTML5 that the spec should be based upon reality, rather than the other way around. |
Agree with @stevehill1981 - we as the internet community should be creating standards in a descriptivist manner. We shouldn't be trying to be L’Académie française for the Internet. Our end goal as makers, as the people who power what goes behind what a lot of people see, should be to improve the experience of the millions of end users that access the services that we collectively power and create. How does this sort of a decision benefit end users? Answer: it doesn't. Let's get back to work on things which are actually important to the world. |
Leave 418 alone! |
What a silly thing to complain about, it's a cute little code that haven't done anything wrong.. |
As others have already observed: even if a new Otherwise, it's a human touch in a piece of pretty complex, future-facing work that everyone uses every day. It's not a bug to have these things in our code. Remember when we added Also: the Internet of Things is so ubiquitous these days that sooner or later, an internet-connected teapot may well need to use this response code. Do we want to be the ones to deny them that opportunity?! |
While we're at this, why not break out the shotgun and blow every pigeon that's part of an RFC1149 implementation out of the sky (or coop)? Or burn all the bongos prematurely? I like 418, used it in Production and I don't even drink tea! :) (edit: add) #Save418 |
Hey, please do not leave #save418 comments - they create a lot of noise. If you'd like to indicate support for/against removing the status code without participating in the technical discussion - please use reactions. I'd like to point out to anyone participating that we are looking for more contributors in Node and there are plenty of issues tagged "good-first-contribution" you're welcome to pick up and we'll help you with. |
@mnot |
@haydenk HTTP 418 is not a part of the HTTP spec. It is OTOH part of an aprils fool joke and now ironically half the internet thinks it is part of the HTTP spec. Now we have @mnot, which is chairing the IETF HTTP working group, saying very specifically why this is not part of the HTTP spec, and the reactions in this thread (and the internet community in general) is quite frankly alarming. The problem with major framework vendors implementing this is backwards compatibility, set aside 418 is not a part of the HTTP standard. IANA says it is unassigned, which can be because it conflicts with existing legacy systems, or may be reserved in the future for other purposes. Some may argue that we should then just use and request 418 to become part of the standard in a future spec. Historically speaking, someone misinterpreted an RFC document (that was an aprils fool) , thought it was a part of the HTTP standard, it somehow slipped through a review process and now node (among many others) think its part of the spec. This is why IMO this is a bug, and I really do not hope of someone making a mistake (or as part of a practical joke) makes this a part of the HTTP spec. To put things in perspective, why don't we start argue that some useless HTTP verb should become a part of the HTTP spec just because the major web framework vendors thought it would be a fun Aprils joke. |
Backwards compatibility to... what? TBH I don't think the IANA registration will go through, it's just a tongue-in-cheek way for @sebdeckers to express his discontent with this change. |
@tyteen4a03 If there is a new spec saying that 418 is used for something else than "Im a teapot", NodeJS would have to deprecate this and phase it out. They cannot simply just remove this as it introduces API changes. |
Backward compatible to our sense of humor, I guess. I agree that there are few, if any, technical reasons in favor of needing 418 Teapot. Despite that, there are no valid reasons to push it so hard for its removal either. I don't buy Mark's claim about the limited space of HTTP error code and I've already stated why that pretense is not sensible. |
While I don't care if 418 remains supported in Node or not (or any other tool/technology) I'd be against IANA registering it for a new purpose, ever. It's been useful as a status code one can use in tests/mocks to make it clear that the error is fake and is not coming from a live system on the other end. Teapot or not, having a HTTP code you can be sure a 3rd party system you're integrating with is not sending back from a legitimate API is useful. What I want to say is hoping for a legitimate use of 418 is not a good argument in this discussion. edit: @sebdeckers you could use this argument in your IANA application too. |
Is this the right place to discuss? If you want to change the standard, please create a RFC. |
This is a low-value change that isn't going to solve the problem of running out of HTTP error codes in the near-future. It will merely delay it by 1, not worth the effort imo. |
This seems like a change that doesn't provide much in the way of value, and could even be considered detrimental in the future - Given the rise of IoT devices, a real-world implementation of HTTP 418 is increasingly likely. |
All, thank you for the amusing and fun feedback. It pleases us all to no end that the most beloved feature of Node.js is a Teapot. I think it's safe for us to leave this as is for now. I'm closing the issue and just to avoid keeping this issue from growing indefinitely for all of time, I'm going to lock it. Sleep in comfort tonight knowing that, at least for the foreseeable future, your Node.js web applications can proudly proclaim that they, too, are Teapots. |
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 notHTTP/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
The text was updated successfully, but these errors were encountered: