@ALTree: This should probably be a Go 2 proposal, net/http.StatusTeapot is used in the wild.

It could still get a Deprecated: doc comment though so tools warn against its use?

Yes, that's right but it looks like there many implementations of the HTCPCP. I think it's ok to break them in a major release of Go since it's not really part of the HTTP specification.

Flexibility is the key here, if users needs to support the 418 status code for some reason, they should be able to extends the Go stdlib.

Edit:

@bradleyfalzon could Go emit a warning at compile time to warn the user about that?

I'll be terse as I don't want to litter this issue, I'm referring to the standard deprecated notices documented https://blog.golang.org/godoc-documenting-go-code 3rd party tools already do check this such as https://staticcheck.io/docs/staticcheck SA1019 | Using a deprecated function, variable, constant or field.

@zegl Yes, removing the 418 constant would break the go1 compat promise... but since it appears to be a joke (is it?) I'll leave to others to decide if it would be fine to remove it. That's why I didn't (yet) tag it as go2.

Doing some git digging... It was added in 5fb82d8

We can remove it from Go 2.

I have another proposal somewhere to hide stuff (symbols, packages) from docs without removing it from the API. This might be a candidate of a thing to hide from docs but keep for compatibility.

SGTM, thanks.

I would be saddened to see 418 removed. It's a fun bit of flavor that does no harm, and is a neat little easter egg to stumble upon - I feel it would be a shame to smother it. Going by the reactions to the related Node issue, it appears I am not the only one.

Why bother? It's amusing, and doesn't hurt anything.

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.

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

We have a history of people squatting on HTTP status codes, and they're a scarce resource. The registry is the mechanism we use to coordinate their semantics and assure interoperability, and this status code is not registered.

I'm all for Easter eggs in headers (effectively infinite space), body content, etc. Putting a joke in a status code isn't a big deal right now, but it sets a precedent of treating this space carelessly, and considering what we hope the lifetime of HTTP will be, it's a concern.

Also, we have a chance of getting rid of this now; when it comes down to that last status code, it'll be far too embedded to get rid of (the resistance we see now will be 100x greater).

I propose removing it from net/http and creating net/htcpcp, because - as many stated before - code 418 is not in fact a HTTP/1.x status code, but HTCPCP/1.0.

Perhaps we should just register 418 officially, and then everyone can be happy.

Also, we have a chance of getting rid of this now; when it comes down to that last status code, it'll be far too embedded to get rid of (the resistance we see now will be 100x greater).

@mnot I would challenge this claim. If your fear is that 418 will gain widespread adoption, I think you're a little late; 418 was introduced in 1998, 19 years ago. Quite the opposite - once HTTP codes start becoming a scarce resource, the value of having a joke code will not be worth taking up a code for.

@birjolaxew I think lots of implementations have included it because they someone thought it was relevant, and they took a pull request without checking. As a proportion of traffic / applications / requests / whatever other metric you choose, it's basically unused for the defined semantics.

We have a history of people squatting on HTTP status codes, and they're a scarce resource.

How is it a scarce resource with over 50% of the space still available? Considering it's taken 19 years to get to the current point I very much doubt that claim. No one seems to be in any need or hurry to introduce additional codes either, and definitely not another 82 of them just in the 4xx range. Unless there's some RFC that we haven't seen yet?

The registry is the mechanism we use to coordinate their semantics and assure interoperability, and this status code is not registered.

Fair enough. Lets just register it then, instead of going on a campaign against it. It's used in plenty of places in the wild, might as well codify it as such.

I'm all for Easter eggs in headers (effectively infinite space), body content, etc. Putting a joke in a status code isn't a big deal right now, but it sets a precedent of treating this space carelessly, and considering what we hope the lifetime of HTTP will be, it's a concern.

That precedent was set 19 years ago. It hasn't caused much of a problem yet. Why the sudden 🔥 now? What 82 status codes do you expect to need in the 4xx space, even during the lifetime of HTTP?

Aside from that, as far as I'm aware it's perfectly possible to come up with HTTP/3 that uses different status codes and ranges. We'll likely keep reusing the same ones b/c it makes interoperability easier and it's what people expect, but there's nothing stopping us from expanding the 4xx range to 4xxx instead or 4xxxxxxx should this ever, truly, become a problem. A 64bit integer can fit a very big 4 with lots of numbers behind it.

Also, we have a chance of getting rid of this now; when it comes down to that last status code, it'll be far too embedded to get rid of (the resistance we see now will be 100x greater).

418 is already in use. Removing it now from Go, or NodeJS, while not removing it from Java, Python, Ruby, and a whole bunch of others does absolutely nothing to solve this problem. As you've noted yourself, even if it's removed from Go there's nothing stopping anyone from introducing it themselves.

If you'd like to get rid of 418, submit an RFC and have it ratified that declares that no standards compliant HTTP implementation may return or interpret 418 in the teapot sense. There is plenty of precedent of RFCs being introduced to obsolete/forbid behaviour that is currently seen in the wild. That's the right way of getting this fixed and settle this debate once and for all.

If you'd like to get rid of 418, submit an RFC and have it ratified that declares that no standards compliant HTTP implementation may return or interpret 418 in the teapot sense.

That's not how it works; we don't define every thing that's not allowed, we define the semantics and record them in the registry.

If you're suggesting we mark the HTCPCP RFCs as Historic, we can do that, but I suspect that will make even more people sad.

If you're suggesting we mark the HTCPCP RFCs as Historic, we can do that, but I suspect that will make even more people sad.

You're already making a lot of people sad. Someone even went so far as to start save418.com because of what is happening. If you look at the emoji reactions, most people here seem unhappy with your proposal. At least doing it that way won't leave it up to language implementations but actually provides a clear signal as to what implementers are expected to do. Sure it's sad if 418 becomes historical but if it's an actual issue that it's being used as it is right now, then that's what should happen.

Regardless of all of this, you still haven't been able to provide an argument as to why supporting 418 is actually harmful aside from some rather unlikely scenario about running out of status codes and that not being able to be solved within HTTP. People at IANA and the IETF know that 418 is used as it is, it's not hard to skip a number. Sure it's not registered, but until it's registered for anything else, why remove it? It won't get removed in Go 1, and Go 2 might never happen. Similarly plenty of other languages have had support for 418 for a decade or more. So this is going to be around for a long long time.

Some people have no sense of humor. This isn't harmful. It's funny.

Regardless of all of this, you still haven't been able to provide an argument as to why supporting 418 is actually harmful. Sure it's not registered, but that's about it.

The argument is quite clear:

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.

An alternative solution, although I think it's fine to schedule the constant's removal, is to remove it from http.StatusText(code int) string function. net/http can continue to define the constant as there's no harm there, but StatusText would not recognise the code, instead reserving it for use by an accepted status code.

I find that argument to be rather weak. I'm onboard with the principle, but I'm having a hard time seeing us running out of status codes or not being able to solve that for this to actually cause any problems.

But, lets assume that next year we run out of 4xx status codes, what then? Freeing up 418 is not a long term solution, we'll have to come up with a different way of handling status codes entirely if this truly is a problem we (the IETF and the internet at large) foresee having anytime soon.

Crossing the streams; also raised in nodejs/node#14644 and aspnet/HttpAbstractions#915

Some people have no sense of humor. This isn't harmful. It's funny.

That's a matter of taste. Go is an opinionated language, and I was surprised to find this status code here. I don't think it's particularly funny or harmful. Due to compatibility, it has to stay in the language. I don't see why it should be deprecated either, does the status code really need to be maintained or acknowledged in any special way?

Someone even went so far as to start save418.com because of what you're trying to do.

It is a bit frighting how much time collectively gets spent on issues like this.

We have a history of people squatting on HTTP status codes, and they're a scarce resource. The registry is the mechanism we use to coordinate their semantics and assure interoperability, and this status code is not registered.

@mnot do you have any examples of this? From the top of my head I can't think of any examples of people squatting HTTP status codes, nor are they a scarce resource when more than half of the 400 are unused.

@sondr3 Plenty here, but none as widely recognised as the 418.

That list is a good start. When we did 451, there was a concern we couldn't use it because Exchange server had squatted on it in the past, but working with MSFT, we determined that it wasn't likely to be an interop problem (because it was confined to one bit of code that was old, not still widely deployed, and specialised, IIRC).

The code 451 was chosen as a reference to the novel Fahrenheit 451.

Isn't this a bit ironic given you want to remove 418 I'm a Teapot? You could've chosen any of the free status codes but you had to use one that's a reference to a novel.

We use 418 in Production. I highly oppose this request.

1. I dislike how this is being done, piecemeal across multiple projects, in a way that disputes there isn't a standard implementation here. This should be raised in an RFC and web server developers like Node and Golang key project members should communicate there, along with browser manufacturers and embedded device manufacturers (see below for more on this last point).

2. I strongly believe there's a finite number of 4xx error cases that you will ever see. The very fact they have grown really slow is indicative to me that we are unlikely to ever need all the space.

3. What is your proposal for current implementations using 418? At the minimum I would expect to see an RFC providing best practice for existing HTCPCP-compliant devices (which do exist). Arguing that it's April 1st RFC is insufficient. It has been published and implemented in practice.

4. 418 is not purely a HTCPCP control code. It's an inter-op code for HTTP given overlapping resources. It indicates that the device is a HTCPCP device and not a standard HTTP device. This displays a fundamental lack of understanding of the RFC. Arguing that HTCPCP is not HTTP is like arguing HTTP/2 is not HTTP.

5. Regarding effort, the coffee pot control protocol has it's earliest origins in the foundation of the internet. See https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot In fact, the Too Early code that is being proposed owes it's existence to the invention of streaming media which the coffee pot played a key part in showing the need for. So from a variety of standpoints the issue is of merit, aside from actual commercial implementations.

6. While the author has linked to one conversation on one RFC for one new code, nowhere has he provided any indication of the claims, namely that:

• Unregistered codes cause problems for RFC writers
• Unregistered codes with small usage rates are actually considered by RFC writers
• The body of opinion of those writing and reading RFCs is behind the view that we will need to rescind non-official codes.

7. The Internet of Things is a key development area for the Internet. HTTP will doubtless provide a useful transport protocol for that medium. Is there room for a more generic 'Wrong Device Type' error code that would preserve the meaning and adoption of the error code while broadening the scope of it's usability beyond the RFC?

Hi! Speaking as part of team "Teapot", which is named based on this error code, I want to have 418 as it is. If you change it you break compatibility, for being too serious. ;)

We really need this client error code for answering questions personally.

Fun fact:
Our web page https://www.google.com/teapot is maybe not very known, while not working for google we appreciate it.

I'm the CTO, CEO of a popular IoT company, you may have heard of it: tPot.

What status code am I supposed to return from my teapots if this is removed from Go? This is ridiculous.

A teapot must have hurt you very deeply for you to take up this crusade against them.

Shame on you sir.

The argument for freeing up 418 for space reasons holds little weight -- it came out nearly 20 years ago and the need for additional space for status codes has yet to become a major issue, even in the rise of HTTP/2.0.

Think about it, nearly 20 years that people have been using this status code. It's been apart of Node, Golang, and others, so of course people have been using it. At work, we have automated tests that check for status errors to ensure the right events happen, and ImATeapot is one we use as a wildcard -- a random status error we know we'd never get back, so we use it to automatically fail the tests. It honestly fits this purpose beautifully -- being both random, and unexpected. We don't want to fail our tests with a realistic error in that case which could be the cause of a bug elsewhere. ImATeapot is perfect for this case.

It's also one of those things when you're new to programming, or working with HTTP when you see it, you can't help but smile and be happy for a moment, remembering how humbling and cute it is sometimes to program computers. Removing this, after nearly 2 decades, just seems a little sad. People love it, and it should stay. There's no effective reason not to. Sure, it's not HTTP standard, okay, I see the argument for wanting to migrate it to HTCPCP, but I just fail to see how this is harming anyone. It's age has nearly made it a standard--every specification listing errors codes online includes it, so why should we not deem it prominent enough to be included?

Please do not comment on the issue unless you have something to say other than "but I like teapots". We have a NoMeToo policy. You can add a reaction to the initial post to show support or opposition to the proposal without cluttering the discussion. Thank you.

We should keep 418. It is used in production, like here: https://www.google.com/teapot

A request to register 418 has been submitted to IANA, under number 979050.

A HTTP spec return code nobody sees and has use for, and that takes space in a spec. Drives a point home about how idiotic node.js, Go and ASP.net communities are.

@cheery Do you have similar feelings about rebeccapurple? Sentimental reasons sometimes lead to inclusions of things that aren't necesarrily required for technical reasons. This bit of humanity in an otherwise technical process is something I (and many others) value.

A HTTP spec return code nobody sees and has use for, and that takes space in a spec. Drives a point home about how idiotic node.js, Go and ASP.net communities are.

Though you might disagree, please refrain for calling others idiots b/c of a difference of opinion. The conversation has been pretty civil so far, lets keep it that way. If you'd like to participate in these discussions, take a look at the Code Of Conduct.

Aside from that, this doesn't just affect Go, Node and ASP.NET. A number of Python clients and servers support it too, so does Ruby in both Net::HTTP and Rails, Perl recognises it too as part of HTTP::Status and the list goes on and on and on and on. Deprecating something like 418 that's pretty pervasive in HTTP implementations should be done properly and through proper process. Going around raising issues on different projects to get it removed is not how that's achieved and robs the community of having these discussions once, and settling on a decision moving forward. It also greatly increases the amount of time and effort that is expensed for something like this. Doing it this way only risks creating greater incompatibilities and not solving the issue at all as some might chose to implement the request whereas others will chose not to.

Though 418 is not officially part of the HTTP RFC, it is part of the internet and when it comes to the internet there is greater value in remaining compatible with existing implementations than breaking it on a purity argument.

If we truly foresee running out of status codes being a likely problem then effort should be expensed instead on updating the HTTP spec to solve this issue. Doing this now would give us ample time to get that rolled out and supported before that happens. HTTP is not set in stone.

If somebody actually believes we are going to run out of HTTP error codes in near future, he/she should try to fix HTTP design.
Having one extra error code isn't going to solve that problem (which I think is fictitious).

Though you might disagree, please refrain for calling others idiots b/c of a difference of opinion.

He called no person an idiot. Collective intelligence actually often falls into that category.

Thank you all for your input. I believe the case has been made clearly both for and against the proposal and while there is nothing that can be done inside the scope of Go 1, this issue will be revisited in the planning for Go 2.

I am closing discussion on this issue as there is nothing more to be said at this time. Thank you.

For future reference, @mnot has drafted https://tools.ietf.org/id/draft-nottingham-thanks-larry-00.html to reserve code 418.

The status of 418 seems to be unresolved. Closing until it is resolved.