418 I'm a Teapot #915

Closed
mnot opened this Issue Aug 10, 2017 · 28 comments

Comments

Projects
None yet
@mnot

mnot commented Aug 10, 2017

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

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Aug 10, 2017

Member

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

Member

davidfowl commented 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

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

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

mnot commented Aug 10, 2017

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

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Aug 10, 2017

Member

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.

Member

davidfowl commented 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

This comment has been minimized.

Show comment
Hide comment
@Eilon

Eilon Aug 10, 2017

Member

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

Member

Eilon commented Aug 10, 2017

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

@MikeBishop

This comment has been minimized.

Show comment
Hide comment
@MikeBishop

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

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

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Aug 10, 2017

Contributor

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

Contributor

benaadams commented Aug 10, 2017

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

@StephanMeijer

This comment has been minimized.

Show comment
Hide comment
@daenney

This comment has been minimized.

Show comment
Hide comment

daenney commented Aug 11, 2017

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

@cheery

This comment has been minimized.

Show comment
Hide comment
@cheery

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

cheery commented 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

This comment has been minimized.

Show comment
Hide comment
@nickaein

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

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

This comment has been minimized.

Show comment
Hide comment
@anfractuosity

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

anfractuosity commented 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

This comment has been minimized.

Show comment
Hide comment

tyteen4a03 commented Aug 11, 2017

Node.js has said no to removing 418.

@agauniyal

This comment has been minimized.

Show comment
Hide comment

Even Go has said no to removing 418.

@nickolasacosta

This comment has been minimized.

Show comment
Hide comment
@nickolasacosta

nickolasacosta Aug 11, 2017

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

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

@tyteen4a03

This comment has been minimized.

Show comment
Hide comment
@tyteen4a03

tyteen4a03 Aug 11, 2017

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

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

@nomadhacker

This comment has been minimized.

Show comment
Hide comment
@nomadhacker

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

nomadhacker commented 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

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot 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,

mnot commented 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

This comment has been minimized.

Show comment
Hide comment
@nomadhacker

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

nomadhacker commented 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

This comment has been minimized.

Show comment
Hide comment
@mnot

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

mnot commented 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

This comment has been minimized.

Show comment
Hide comment
@anfractuosity

anfractuosity 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:

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 commented 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:

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.

@nickaein

This comment has been minimized.

Show comment
Hide comment
@nickaein

nickaein Aug 11, 2017

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

nickaein commented Aug 11, 2017

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

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Aug 11, 2017

Contributor

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

Contributor

benaadams commented 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

This comment has been minimized.

Show comment
Hide comment
@mnot

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

mnot commented 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

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Aug 11, 2017

Contributor

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,

Contributor

benaadams commented 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

This comment has been minimized.

Show comment
Hide comment
Contributor

benaadams commented Aug 11, 2017

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

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

mnot commented 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

This comment has been minimized.

Show comment
Hide comment
@glennc

glennc Aug 11, 2017

Member

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.

Member

glennc commented 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 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.

@glennc glennc closed this Aug 11, 2017

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

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

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

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