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

Closed
mnot opened this Issue Aug 6, 2017 · 56 comments

Comments

Projects
None yet
@mnot
Contributor

mnot commented Aug 6, 2017

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

@Trott

This comment has been minimized.

Show comment
Hide comment
Member

Trott commented Aug 6, 2017

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 6, 2017

Member

"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.

Member

jasnell commented Aug 6, 2017

"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.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Aug 6, 2017

Contributor

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.

Contributor

mscdex commented Aug 6, 2017

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.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 6, 2017

Member

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

Member

jasnell commented Aug 6, 2017

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

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 6, 2017

Contributor

WFM, thanks. I'll chase Go.

Contributor

mnot commented Aug 6, 2017

WFM, thanks. I'll chase Go.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Aug 8, 2017

Member

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?

Member

Fishrock123 commented Aug 8, 2017

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?

jasnell added a commit to jasnell/node that referenced this issue Aug 8, 2017

@jasnell jasnell referenced this issue Aug 8, 2017

Closed

http: docs deprecation of 418 teapot status #14693

0 of 4 tasks complete
@birjolaxew

This comment has been minimized.

Show comment
Hide comment
@birjolaxew

birjolaxew Aug 10, 2017

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? 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).

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 10, 2017

Member

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.

Member

jasnell commented Aug 10, 2017

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.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Aug 10, 2017

Member

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.

Member

addaleax commented Aug 10, 2017

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.

@alexdresko

This comment has been minimized.

Show comment
Hide comment
@alexdresko

alexdresko Aug 10, 2017

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

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

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

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

@birjolaxew

This comment has been minimized.

Show comment
Hide comment
@birjolaxew

birjolaxew Aug 10, 2017

@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.

birjolaxew commented Aug 10, 2017

@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.

@tyteen4a03

This comment has been minimized.

Show comment
Hide comment
@tyteen4a03

tyteen4a03 Aug 10, 2017

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.

tyteen4a03 commented Aug 10, 2017

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.

@WhataShane

This comment has been minimized.

Show comment
Hide comment
@WhataShane

WhataShane Aug 10, 2017

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. 🙂)

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. 🙂)

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 10, 2017

Member

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.

Member

jasnell commented Aug 10, 2017

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.

@tyteen4a03

This comment has been minimized.

Show comment
Hide comment
@tyteen4a03

tyteen4a03 Aug 10, 2017

The thread is here if anybody is interested.

The thread is here if anybody is interested.

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 10, 2017

Member

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)

Member

refack commented Aug 10, 2017

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)

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

Contributor

@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

Contributor

mnot commented Aug 10, 2017

@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

@maxh213

This comment has been minimized.

Show comment
Hide comment
@maxh213

maxh213 Aug 10, 2017

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.

maxh213 commented Aug 10, 2017

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.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

Contributor

@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.

Contributor

mnot commented Aug 10, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 10, 2017

Member

@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.

Member

refack commented Aug 10, 2017

@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.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

Contributor

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.

Contributor

mnot commented Aug 10, 2017

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.

@WhataShane

This comment has been minimized.

Show comment
Hide comment
@WhataShane

WhataShane Aug 10, 2017

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?

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?

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 10, 2017

Member

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

Member

refack commented Aug 10, 2017

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

@maxh213

This comment has been minimized.

Show comment
Hide comment
@maxh213

maxh213 Aug 10, 2017

@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.

maxh213 commented Aug 10, 2017

@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.

@birjolaxew

This comment has been minimized.

Show comment
Hide comment
@birjolaxew

birjolaxew Aug 10, 2017

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

@mnot 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.

Regardless, there is little harm in implementing 418 in Node - notably, it does not go against the HTTP protocol (where 418 is "Unassigned", not "Disallowed").

birjolaxew commented Aug 10, 2017

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

@mnot 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.

Regardless, there is little harm in implementing 418 in Node - notably, it does not go against the HTTP protocol (where 418 is "Unassigned", not "Disallowed").

@strugee

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee Aug 10, 2017

Contributor

@maxh213:

honestly you can just put another 0 on the end and we can have 1000 status codes

No, you can't. This would be a major breaking change and would break all implementations that (very reasonably) just assume they can do e.g. status <= 500 && status > 400 to determine if the server had an error, of any kind. This is even forward compatible even if new statuses are added that the client doesn't know about.

Also you're assuming HTTP 3 will still use status codes

Such a protocol would be very different from HTTP and arguably deserving of a different name. Plus, you're assuming that there even will be an HTTP/3. Ideally, we would just keep doing backwards-compatible things and not even need HTTP/3.

Contributor

strugee commented Aug 10, 2017

@maxh213:

honestly you can just put another 0 on the end and we can have 1000 status codes

No, you can't. This would be a major breaking change and would break all implementations that (very reasonably) just assume they can do e.g. status <= 500 && status > 400 to determine if the server had an error, of any kind. This is even forward compatible even if new statuses are added that the client doesn't know about.

Also you're assuming HTTP 3 will still use status codes

Such a protocol would be very different from HTTP and arguably deserving of a different name. Plus, you're assuming that there even will be an HTTP/3. Ideally, we would just keep doing backwards-compatible things and not even need HTTP/3.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Aug 10, 2017

Crossing the streams; also raised in golang/go#21326 and aspnet/HttpAbstractions#915

Crossing the streams; also raised in golang/go#21326 and aspnet/HttpAbstractions#915

@CSobol

This comment has been minimized.

Show comment
Hide comment
@CSobol

CSobol Aug 10, 2017

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

Good. They can use 418 after 400-417 and 419-499 are filled. 418 should live as "I'm a teapot" as long as possible.

CSobol commented Aug 10, 2017

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

Good. They can use 418 after 400-417 and 419-499 are filled. 418 should live as "I'm a teapot" as long as possible.

@haydenk

This comment has been minimized.

Show comment
Hide comment
@haydenk

haydenk Aug 11, 2017

Is it causing any harm to Node? Joke or not, is it legitimately part of the HTTP spec?

haydenk commented Aug 11, 2017

Is it causing any harm to Node? Joke or not, is it legitimately part of the HTTP spec?

@MaxSem

This comment has been minimized.

Show comment
Hide comment
@MaxSem

MaxSem Aug 11, 2017

I'm usually a rabid pro-deprecation warrior, even if it breaks someone's code. Because you can never avoid breaking anything anyway, even if you're fixing a noncontroversial bug. However, I find this request petty and against the spirit of open source software.

Code 418 is a well-known easter egg in the history of internet protocols and RFCs themselves. It's part of our history. Supporting a single constant in one place does not incur any maintenance burden, and requester's assertion that having this constant would be problematic some time 50 years from now when we will still be using HTTP and run out of status codes does not hold water.

MaxSem commented Aug 11, 2017

I'm usually a rabid pro-deprecation warrior, even if it breaks someone's code. Because you can never avoid breaking anything anyway, even if you're fixing a noncontroversial bug. However, I find this request petty and against the spirit of open source software.

Code 418 is a well-known easter egg in the history of internet protocols and RFCs themselves. It's part of our history. Supporting a single constant in one place does not incur any maintenance burden, and requester's assertion that having this constant would be problematic some time 50 years from now when we will still be using HTTP and run out of status codes does not hold water.

@sebdeckers

This comment has been minimized.

Show comment
Hide comment
@sebdeckers

sebdeckers Aug 11, 2017

Contributor

Since a major argument for deprecating the 418 status code is its lack of IANA registration, why not actually register it?

The IANA HTTP Status Code Registry shows 418 as unassigned and, presumably, is unlikely to assign this value to any other status code given the de-facto conflicting adoption in many (arguably legacy/broken) implementations.

Contributor

sebdeckers commented Aug 11, 2017

Since a major argument for deprecating the 418 status code is its lack of IANA registration, why not actually register it?

The IANA HTTP Status Code Registry shows 418 as unassigned and, presumably, is unlikely to assign this value to any other status code given the de-facto conflicting adoption in many (arguably legacy/broken) implementations.

@sebdeckers

This comment has been minimized.

Show comment
Hide comment
@sebdeckers

sebdeckers Aug 11, 2017

Contributor

Okay so I've gone ahead and submitted the application, come what may:


To whom it may concern:

This is an automatically generated message to notify you that we have
received your request, and it has been recorded in our ticketing
system with a reference number of 979050.

There is no need to reply to this message right now. IANA staff will
review your message shortly.

If this message is in reply to a previously submitted ticket, it is
possible that the previous ticket has been marked as closed. As we
review this ticket, we will also review previous correspondence and
take appropriate action.

To expedite processing, and ensure our staff can view the full history
of this request, please make sure you include the follow exact text in
the subject line of all future correspondence on this issue:

     [IANA #979050]

You can also simply reply to this message, as this tag is already in
the subject line.

Thank you,

IANA Services
iana-questions@iana.org
PTI


Contact Name:
Sebastiaan Deckers

Contact Email:
sebdeckers83@gmail.com

Type of Assignment:
Value: 418
Description: I'm a teapot

Registry:
HTTP Status Codes

Description:
Efforts to remove the 418 status code from popular HTTP implementations (Node.js, Go, Request) were met with vocal user resistance (e.g. http://save418.com, #14644, requests/requests#4238 (comment)).

About half of the 4xx codes are still unassigned so there is currently little need to "free up" 418 for scarcity reasons.

De-facto adoption of 418 (perhaps more widely than many assigned status codes, due to its joking nature) means it is undesirable to assign the value to future specifications. Doing so could lead to conflicts with many legacy implementations.

Deprecating 418 from existing code bases requires some implementations to go through a major release cycle. This process can take several years. (e.g. #14644 (comment))

Registering the 418 status code will bring standards compliance to existing HTTP implementations with minimal effort. Implementations that do not currently implement 418 would add support as with any newly assigned status code. Implementations that already support it remain unaffected.

The change should be mostly backwards compatible, as the status code has never been assigned otherwise (AFAIK).

Wile RFC2324 defines a made-up, April Fool's, joke protocol (HTCPCP/1.0), the value/description defined in 2.3.2 are implied to be an HTTP/1.1-compatible status code & message. The document makes multiple references to being "based on HTTP."

Additional Info:
https://www.ietf.org/rfc/rfc2324.txt
https://tools.ietf.org/html/rfc7231

Contributor

sebdeckers commented Aug 11, 2017

Okay so I've gone ahead and submitted the application, come what may:


To whom it may concern:

This is an automatically generated message to notify you that we have
received your request, and it has been recorded in our ticketing
system with a reference number of 979050.

There is no need to reply to this message right now. IANA staff will
review your message shortly.

If this message is in reply to a previously submitted ticket, it is
possible that the previous ticket has been marked as closed. As we
review this ticket, we will also review previous correspondence and
take appropriate action.

To expedite processing, and ensure our staff can view the full history
of this request, please make sure you include the follow exact text in
the subject line of all future correspondence on this issue:

     [IANA #979050]

You can also simply reply to this message, as this tag is already in
the subject line.

Thank you,

IANA Services
iana-questions@iana.org
PTI


Contact Name:
Sebastiaan Deckers

Contact Email:
sebdeckers83@gmail.com

Type of Assignment:
Value: 418
Description: I'm a teapot

Registry:
HTTP Status Codes

Description:
Efforts to remove the 418 status code from popular HTTP implementations (Node.js, Go, Request) were met with vocal user resistance (e.g. http://save418.com, #14644, requests/requests#4238 (comment)).

About half of the 4xx codes are still unassigned so there is currently little need to "free up" 418 for scarcity reasons.

De-facto adoption of 418 (perhaps more widely than many assigned status codes, due to its joking nature) means it is undesirable to assign the value to future specifications. Doing so could lead to conflicts with many legacy implementations.

Deprecating 418 from existing code bases requires some implementations to go through a major release cycle. This process can take several years. (e.g. #14644 (comment))

Registering the 418 status code will bring standards compliance to existing HTTP implementations with minimal effort. Implementations that do not currently implement 418 would add support as with any newly assigned status code. Implementations that already support it remain unaffected.

The change should be mostly backwards compatible, as the status code has never been assigned otherwise (AFAIK).

Wile RFC2324 defines a made-up, April Fool's, joke protocol (HTCPCP/1.0), the value/description defined in 2.3.2 are implied to be an HTTP/1.1-compatible status code & message. The document makes multiple references to being "based on HTTP."

Additional Info:
https://www.ietf.org/rfc/rfc2324.txt
https://tools.ietf.org/html/rfc7231

@wswoodruff

This comment has been minimized.

Show comment
Hide comment
@wswoodruff

wswoodruff Aug 11, 2017

The hapi community supports 418 Teapot! Boom is a core module in hapi
https://github.com/hapijs/boom/search?utf8=✓&q=teapot

The hapi community supports 418 Teapot! Boom is a core module in hapi
https://github.com/hapijs/boom/search?utf8=✓&q=teapot

@haydenk

This comment has been minimized.

Show comment
Hide comment
@haydenk

haydenk Aug 11, 2017

To be accepted, I would like to see a Youtube video of @mnot singing "I'm a little teapot" complete with hand motions.

haydenk commented Aug 11, 2017

To be accepted, I would like to see a Youtube video of @mnot singing "I'm a little teapot" complete with hand motions.

@JoshCheek

This comment has been minimized.

Show comment
Hide comment
@JoshCheek

JoshCheek Aug 11, 2017

@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).

I count 69 available 4XX status codes on IANA. If we need all 69 that badly, then isn't it inevitable that we will also need 70?

The reality is that if we get to this point, someone will modify the protocol. Maybe allow periods 400.12 or choose the most-significant-digit so that 4001 is grouped with 400 level, or choose that the 600s extend the 400s, or allow hex digits so that 499 + 1 = 49A Lots of possibilities, there's no value in pedantry here.

@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).

I count 69 available 4XX status codes on IANA. If we need all 69 that badly, then isn't it inevitable that we will also need 70?

The reality is that if we get to this point, someone will modify the protocol. Maybe allow periods 400.12 or choose the most-significant-digit so that 4001 is grouped with 400 level, or choose that the 600s extend the 400s, or allow hex digits so that 499 + 1 = 49A Lots of possibilities, there's no value in pedantry here.

@cookiengineer

This comment has been minimized.

Show comment
Hide comment
@cookiengineer

cookiengineer Aug 11, 2017

@JoshCheek: I would agree with that point. It will probably happen similar to the WS13+ protocol (websockets), and be placed after an UPGRADE of the connection has happened.

I mean, even HTTP/2.0 (or SPDY) were being placed after an upgrade of the protocol; so the chances HTTP/3.0 will use everything without an upgrade and with a HTTP/1.1 header and with the same range of status codes is very unlikely - as later protocol versions already use the upgrade mechanism for legacy compatibility reasons.

cookiengineer commented Aug 11, 2017

@JoshCheek: I would agree with that point. It will probably happen similar to the WS13+ protocol (websockets), and be placed after an UPGRADE of the connection has happened.

I mean, even HTTP/2.0 (or SPDY) were being placed after an upgrade of the protocol; so the chances HTTP/3.0 will use everything without an upgrade and with a HTTP/1.1 header and with the same range of status codes is very unlikely - as later protocol versions already use the upgrade mechanism for legacy compatibility reasons.

@mashedkeyboard

This comment has been minimized.

Show comment
Hide comment
@mashedkeyboard

mashedkeyboard Aug 11, 2017

I would like to suggest a counter proposal: the incorporation of HTCPCP into the HTTP standard.

I would like to suggest a counter proposal: the incorporation of HTCPCP into the HTTP standard.

@vacri

This comment has been minimized.

Show comment
Hide comment
@vacri

vacri Aug 11, 2017

Just a bystander, but felt the need to say - the 400-block is 69% free. HTTP started development in 1989, and 28 years later we have only 31 400-block codes. Assuming this burn-rate continues (which it won't), it'll be around the year 2100 when we'd 'need' to free up a 400-block code.

Is it normal for nodejs to plan this far ahead when making technical decisions?

vacri commented Aug 11, 2017

Just a bystander, but felt the need to say - the 400-block is 69% free. HTTP started development in 1989, and 28 years later we have only 31 400-block codes. Assuming this burn-rate continues (which it won't), it'll be around the year 2100 when we'd 'need' to free up a 400-block code.

Is it normal for nodejs to plan this far ahead when making technical decisions?

@jdmansour

This comment has been minimized.

Show comment
Hide comment
@jdmansour

jdmansour Aug 11, 2017

In what fashion does Node support status 418 anyway? Isn't it just the default body if you return status 418?

If there was a default message for other codes, like:

if (is_unassigned(status)) {
    message = "Hello, this is the default message for HTTP " + status;
}

would people complain about Node supporting other non-standard status codes like 419?

It would be a different situation if there was a full teapot module, or something depended on this behavior. But the way it is right now, there is no technical impediment for somebody else to go ahead and just assign a meaning to 418. It would be unfortunate, we'd lose a joke. But it would probably be a one line change to replace "I'm not a teapot" with the new meaning.

(As an aside, if anything it might be harmful to register 418 officially with the joke meaning, because that does preclude future usage! Bringing the spec and the implementation in line just for the sake of it, by changing the spec, is silly. Edit: I mean in the case of a silly joke, not in general. If 419 is used by somebody as "I'm a platypus", please don't standardize it. If 420 is in wide use with a sensible meaning, sure, go ahead!)

jdmansour commented Aug 11, 2017

In what fashion does Node support status 418 anyway? Isn't it just the default body if you return status 418?

If there was a default message for other codes, like:

if (is_unassigned(status)) {
    message = "Hello, this is the default message for HTTP " + status;
}

would people complain about Node supporting other non-standard status codes like 419?

It would be a different situation if there was a full teapot module, or something depended on this behavior. But the way it is right now, there is no technical impediment for somebody else to go ahead and just assign a meaning to 418. It would be unfortunate, we'd lose a joke. But it would probably be a one line change to replace "I'm not a teapot" with the new meaning.

(As an aside, if anything it might be harmful to register 418 officially with the joke meaning, because that does preclude future usage! Bringing the spec and the implementation in line just for the sake of it, by changing the spec, is silly. Edit: I mean in the case of a silly joke, not in general. If 419 is used by somebody as "I'm a platypus", please don't standardize it. If 420 is in wide use with a sensible meaning, sure, go ahead!)

@stevehill1981

This comment has been minimized.

Show comment
Hide comment
@stevehill1981

stevehill1981 Aug 11, 2017

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.

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.

@mashedkeyboard

This comment has been minimized.

Show comment
Hide comment
@mashedkeyboard

mashedkeyboard Aug 11, 2017

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.

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.

@StephanMeijer

This comment has been minimized.

Show comment
Hide comment
@StephanMeijer

StephanMeijer Aug 11, 2017

Leave 418 alone!

Leave 418 alone!

@Convery

This comment has been minimized.

Show comment
Hide comment
@Convery

Convery Aug 11, 2017

What a silly thing to complain about, it's a cute little code that haven't done anything wrong..

Convery commented Aug 11, 2017

What a silly thing to complain about, it's a cute little code that haven't done anything wrong..

@mattandrews

This comment has been minimized.

Show comment
Hide comment
@mattandrews

mattandrews Aug 11, 2017

As others have already observed: even if a new 4xx error type comes up, surely the next candidate for its number will not be 418, because of this ambiguity. Even if it's technically "free" to use, surely it'd be avoided because most people will have heard of it because of this teapot joke?

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 rebeccapurple as a colour value? These things remind us that real people made these standards and tools and real people are using them and working with them. Sure, 418 I'm A Teapot is a joke, a bit of fun – but why is this a reason to remove it?

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?!

As others have already observed: even if a new 4xx error type comes up, surely the next candidate for its number will not be 418, because of this ambiguity. Even if it's technically "free" to use, surely it'd be avoided because most people will have heard of it because of this teapot joke?

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 rebeccapurple as a colour value? These things remind us that real people made these standards and tools and real people are using them and working with them. Sure, 418 I'm A Teapot is a joke, a bit of fun – but why is this a reason to remove it?

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?!

@dslmeinte

This comment has been minimized.

Show comment
Hide comment
@dslmeinte

dslmeinte Aug 11, 2017

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

dslmeinte commented Aug 11, 2017

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

@nodejs nodejs deleted a comment from Aggamemnon Aug 11, 2017

@nodejs nodejs deleted a comment from TimothyGu Aug 11, 2017

@nodejs nodejs deleted a comment from ScholtenSeb Aug 11, 2017

@nodejs nodejs deleted a comment from jmurphyau Aug 11, 2017

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Aug 11, 2017

Member

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.

Member

benjamingr commented Aug 11, 2017

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.

@nodejs nodejs deleted a comment from stlk Aug 11, 2017

@nodejs nodejs deleted a comment from CodeWriter23 Aug 11, 2017

@nodejs nodejs deleted a comment from dwardu89 Aug 11, 2017

@nickaein

This comment has been minimized.

Show comment
Hide comment
@nickaein

nickaein Aug 11, 2017

@mnot
If you believe we are going to run out of HTTP error codes in near future, you should try to find a way to fix the design. A single error code isn't going to solve that.

@mnot
If you believe we are going to run out of HTTP error codes in near future, you should try to find a way to fix the design. A single error code isn't going to solve that.

@martinmine

This comment has been minimized.

Show comment
Hide comment
@martinmine

martinmine Aug 11, 2017

@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.

martinmine commented Aug 11, 2017

@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.

@tyteen4a03

This comment has been minimized.

Show comment
Hide comment
@tyteen4a03

tyteen4a03 Aug 11, 2017

The problem with major framework vendors implementing this is backwards compatibility

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 commented Aug 11, 2017

The problem with major framework vendors implementing this is backwards compatibility

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.

@nodejs nodejs deleted a comment from davchana Aug 11, 2017

@martinmine

This comment has been minimized.

Show comment
Hide comment
@martinmine

martinmine Aug 11, 2017

@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.

@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.

@nickaein

This comment has been minimized.

Show comment
Hide comment
@nickaein

nickaein Aug 11, 2017

Backwards compatibility to... what?

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.
A better argument for the removal of 418 is welcomed.

nickaein commented Aug 11, 2017

Backwards compatibility to... what?

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.
A better argument for the removal of 418 is welcomed.

@nodejs nodejs deleted a comment from cheery Aug 11, 2017

@naugtur

This comment has been minimized.

Show comment
Hide comment
@naugtur

naugtur Aug 11, 2017

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.

naugtur commented Aug 11, 2017

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.

@elgohr

This comment has been minimized.

Show comment
Hide comment
@elgohr

elgohr Aug 11, 2017

Is this the right place to discuss? If you want to change the standard, please create a RFC.
In my opinion Node should implement the standard as it is. Otherwise we wouldn't need standards.

elgohr commented Aug 11, 2017

Is this the right place to discuss? If you want to change the standard, please create a RFC.
In my opinion Node should implement the standard as it is. Otherwise we wouldn't need standards.

@umpox

This comment has been minimized.

Show comment
Hide comment
@umpox

umpox Aug 11, 2017

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.

umpox commented Aug 11, 2017

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.

@nodejs nodejs deleted a comment from J7mbo Aug 11, 2017

@nodejs nodejs deleted a comment from captainbland Aug 11, 2017

@Rohaq

This comment has been minimized.

Show comment
Hide comment
@Rohaq

Rohaq Aug 11, 2017

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.

Rohaq commented Aug 11, 2017

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.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 11, 2017

Member

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.

Member

jasnell commented Aug 11, 2017

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.

@jasnell jasnell closed this Aug 11, 2017

@nodejs nodejs locked and limited conversation to collaborators Aug 11, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.