Go HTTP implements the 418 I'm a Teapot status code in go/src/net/http/status.go.

Its reference is RFC7168, but really came from 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.

Node's support for the HTCPCP 418 I'm a Teapot status code (see nodejs/node#14644) 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 Go HTTP, 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 Go easily enough if they want to play with non-standard semantics.

Thanks,

/cc @bradfitz

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

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.

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 nothing to solve this problem. If you'd like to get rid of 418, submit an RFC and have it ratified that declares that no standards compliant implementation may return 418 in the teapot sense.

As a proportion of traffic / applications / requests / whatever other metric you choose, it's basically unused for the defined semantics.

Based on which numbers and what research did you conclude this? And why does this matter for a harmless joke?