Repository navigation
418 I'm a Teapot #915
Description
asp.net 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 asp.net, 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 it easily enough if they want to play with non-standard semantics.
Thanks,
/cc @MikeBishop
Activity
davidfowl commentedon Aug 10, 2017
@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.
mnot commentedon Aug 10, 2017
Scheduling it for a major release is fine. It's a long-term concern, not something urgent.
davidfowl commentedon Aug 10, 2017
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.
Eilon commentedon Aug 10, 2017
Plus it's a funny little thing that harms no one.
MikeBishop commentedon Aug 10, 2017
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.
benaadams commentedon Aug 10, 2017
Crossing the streams; also raised in golang/go#21326 and nodejs/node#14644
StephanMeijer commentedon Aug 11, 2017
See also psf/requests#4238
daenney commentedon Aug 11, 2017
A request to register 418 has been submitted to IANA, under number 979050.
cheery commentedon Aug 11, 2017
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.
nickaein commentedon Aug 11, 2017
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).
anfractuosity commentedon Aug 11, 2017
@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.
tyteen4a03 commentedon Aug 11, 2017
Node.js has said no to removing 418.
agauniyal commentedon Aug 11, 2017
Even Go has said no to removing 418.
tyteen4a03 commentedon Aug 11, 2017
@agauniyal In Go 1. They will revisit the issue in Go 2. So not yet.
nomadhacker commentedon Aug 11, 2017
@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.
mnot commentedon Aug 11, 2017
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,
nomadhacker commentedon Aug 11, 2017
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.
mnot commentedon Aug 11, 2017
Expanding the space of status codes is pretty much impossible; we can't make such a backwards-incompatible change to the Web.
anfractuosity commentedon Aug 11, 2017
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:
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.
nickaein commentedon Aug 11, 2017
@anfractuosity
Yeah that could be one possible approach. However:
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.
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>benaadams commentedon Aug 11, 2017
@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 😸
mnot commentedon Aug 11, 2017
@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.
benaadams commentedon Aug 11, 2017
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,
benaadams commentedon Aug 11, 2017
PS nice URL https://mnot.github.io/I-D/thanks-larry/
mnot commentedon Aug 11, 2017
I'm sure Larry is highly amused by all of this (if he's aware; I think he's on sabbatical right now).
glennc commentedon Aug 11, 2017
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
StatusCodessource 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.mnot commentedon Aug 11, 2017
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.