@mnot What do you want us to do concretely? Remove it from the StatusCodes type? That's a breaking change so it won't happen until potentially 3.0.

That said, I don't see any point in removing it now because there's no harm having it and it's a breaking change. Had this request happened before 1.0, maybe, now it just feels like a purity argument.

Scheduling it for a major release is fine. It's a long-term concern, not something urgent.

I'm just saying it's a very low value breaking change so I don't see a reason to do it ever or at least until it's re-purposed and becomes the replacement.

Plus it's a funny little thing that harms no one.

Until there's an actual registration at that codepoint. Having seen that discussion on the mailing list, there's some hesitancy to reuse a codepoint that implementations already have code for, but it's still an open code that could get assigned in the future.

I'd feel more strongly about making a breaking change here if there were an assigned status code at 418 that we were changing it to. But even then, I'd probably just put a second constant in that has the same value as Status418ImATeapot.

Crossing the streams; also raised in golang/go#21326 and nodejs/node#14644

See also kennethreitz/requests#4238

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.

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

@mnot I'm confused why you're so against 418 in Go, Asp and Node? It hardly remotely effects performance or maintainability.

"one day we may need this code point" - I'm sure there's plenty more numbers which could be utilised, that seems a very poor reason to remove it.

If we ever reach a point were the lack of status codes is an issue, I'm sure the lack of a single extra status code is the least of our worries.

Node.js has said no to removing 418.

Even Go has said no to removing 418.

"... and so he filed a github issue, ensuring that everyone would join the teapot revolution..." - George Orwell

@agauniyal In Go 1. They will revisit the issue in Go 2. So not yet.

@mnot I fail to see the utility in your reasoning. If we reach a point where we have only 1 4xx code left to use (418), then the problem would not be that we have 418 squatting, but that we are running out of codes in the first place.

If we even come remotely near running out of codes to the point where 1 code would make a difference, the obvious solution is not to free up a single code, but to rework the HTTP v.x design to obviate the issue and expand the available pool.

Hey @nomadhacker -

The reasoning is that when a status code is squatted upon, it gets harder to displace as time goes by. We've had cases where deploying a new status code is more difficult because someone has squatted upon it previously (this happened with 451, but we were able to work around that).

There's a bit of history here. It had been asserted a while back (when we did RFC723x) that no one would take 418 seriously, thus we didn't need to reserve it, and could freely reuse it. More recently, when we tried to actually do so, concern about conflict with existing implementations was expressed.

I opened these issues to clarify what the implementers wanted to do; it's pretty clear that they want to continue to squat on 418 -- lots of people love a silly joke -- so we'll adjust; see https://mnot.github.io/I-D/thanks-larry/.

It'd be really helpful if you could note the non-standard status of 418 in your documentation and source, so that people are aware that one day (far, far in the future), it might change.

Cheers,

I still feel that the effort of reclaiming individual codes, if you end up in the future nearing capacity, would be better spent reworking the standard.

Also, as noted in other linked threads on different frameworks, 418 has been widely used in some communities in test frameworks as an indicator of a non-production use status code. Having such a code is surely a useful utility at times.

Expanding the space of status codes is pretty much impossible; we can't make such a backwards-incompatible change to the Web.

Since status codes seemingly follow the format 4xx, for client errors and the same format for others. Would it not be possible to later, add additional ones in the format 4xxx (assuming there will only ever be 1 digit for the type of status code, which is maybe unreasonable).

Existing code then would not need to be altered for 3 digit codes. For instance, if statuses are being checked using simple if statements such as:

if x >= 400 and x <= 499

It would then be a simple case of determining the first digit of the status code if necessary. For detecting these 4 digit status codes and handling appropriately.

4 digit statuses would be simply ignored by devices incompatible with them as far as I can tell,
however that does assume interpretation of status code gracefully handles larger numbers.

However I'm assuming status codes are already represented using at least a 16 bit number, considering, the number 500, requires more than 8 bits to represent.

@anfractuosity

Yeah that could be one possible approach. However:

1. There is no indication that we run out of HTTP error codes anytime. There are ~%50 of them available now and most of them are assigned in early days of HTTP. There are hardly any imaginable scenario that we are out of them.

2. Even if we assume some day we end up assigning all 4xx error codes, having one or two extra error codes is not going to have us. We will have to take the pain and find a workaround to fix it, like the one you proposed.

<rant>
I believe this controversy around 418 (I'm a teapot) is personal obsession and not a technical concern. If I were concerned about running out of HTTP codes, I was spending my time on finding a was to extend HTTP codes instead of wasting everybody's time, including myself, about a pointless issue.
</rant>

@mnot isn't it a bit of a non-issue? (the teapot bit)

For the servers removing the numeric status code is a big problem (compile error level) - so its a bit no go.

However, changing the reason phrase isn't as big a deal; if it was being assigned a use (Is the reason phrase checked much anyway?) Though people would probably have similar objections.

It also has precedence; for example RFC2616 -> RFC7231 status 413 was previously "Request Entity Too Large" and changed to "Payload Too Large".

Obviously in that example they are similar uses.

Could you argue "I'm a teapot" is a similar to the proposed status "Too Early"?

Well going down the rabbit hole...

The Mad Hatter was always worried about being Late to his Tea Party; clearly if you got there and it was just a teapot, then that would probably be Too Early.

Also most of the feedback on the status codes has been that changing it before they are closer to running out is also Too Early...

So... maybe 😸

@benaadams - I was just interested in finding out where implementations stood on this; it had been previously asserted that we didn't have to reserve the status code, because it was "obvious" that it was a joke and could be replaced. That's pretty clearly not the case.

I anticipated having a short, professional discussion with a few implementers, not having a free-for-all; oh well. In any case, as per above you can probably close this issue; the current plan is to reserve the status code to clarify its standing. Like I said, a note in documentation and/or source would be helpful.

Removing the compile time numeric constant 418 would be very problematic (potential compile time errors; runtime errors on library upgrade via binary contract break).

Changing the reason phrase less so (potential runtime errors if people are checking 418 to see whether its both 418 and not a teapot). However, reason phrases can be manually overridden anyway to set the text.

Though, it seems a resolution has been reached,

PS nice URL https://mnot.github.io/I-D/thanks-larry/

I'm sure Larry is highly amused by all of this (if he's aware; I think he's on sabbatical right now).

We can revisit this when we do a 3.0 release if we need to. There is nothing to be done right now.

I don't think we have any explicit documentation that would be a candidate to make a note in, though people can shout out if there is something I'm missing. The StatusCodes source links to http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml which lists 418 as unassigned, but there is precedence for adding comments for clarification on specific codes as RFCs change them. I could see us adding a comment to 418 pointing to an RFC that reserves it, should that RFC end up existing. I don't personally think that adding comments here helps a great deal because I don't think they are really read by anyone, but I am not opposed to it either.

Makes sense, thanks. The comment isn't for general readers, it's an indication of what the implementation's stance is when that day (eventually) comes. We folks in standards bodies do pay attention to implementations, and having clear signals really helps us.