New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: remove support for status code 418 I'm a Teapot #21326

Closed
mnot opened this Issue Aug 6, 2017 · 43 comments

Comments

Projects
None yet
@mnot

mnot commented Aug 6, 2017

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 ALTree changed the title from 418 I'm a Teapot to net/http: remove support for status code 418 I'm a Teapot Aug 6, 2017

@ALTree ALTree added the NeedsDecision label Aug 6, 2017

@ALTree ALTree added this to the Go1.10 milestone Aug 6, 2017

@zegl

This comment has been minimized.

Show comment
Hide comment
@zegl

zegl Aug 6, 2017

Contributor

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

Contributor

zegl commented Aug 6, 2017

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

@bradleyfalzon

This comment has been minimized.

Show comment
Hide comment
@bradleyfalzon

bradleyfalzon Aug 6, 2017

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

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

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Aug 6, 2017

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?

xtuc commented Aug 6, 2017

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?

@bradleyfalzon

This comment has been minimized.

Show comment
Hide comment
@bradleyfalzon

bradleyfalzon Aug 6, 2017

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.

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.

@ALTree

This comment has been minimized.

Show comment
Hide comment
@ALTree

ALTree Aug 6, 2017

Member

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

Member

ALTree commented Aug 6, 2017

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

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Aug 6, 2017

Member

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.

Member

bradfitz commented Aug 6, 2017

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.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 7, 2017

SGTM, thanks.

mnot commented Aug 7, 2017

SGTM, thanks.

@birjolaxew

This comment has been minimized.

Show comment
Hide comment
@birjolaxew

birjolaxew Aug 10, 2017

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.

birjolaxew commented Aug 10, 2017

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.

@tabacco

This comment has been minimized.

Show comment
Hide comment
@tabacco

tabacco Aug 10, 2017

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

tabacco commented Aug 10, 2017

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

@ALTree ALTree modified the milestones: Unplanned, Go1.10 Aug 10, 2017

@romellem

This comment has been minimized.

Show comment
Hide comment
@romellem

romellem Aug 10, 2017

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

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

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

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

mnot commented Aug 10, 2017

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

@irth

This comment has been minimized.

Show comment
Hide comment
@irth

irth Aug 10, 2017

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.

irth commented Aug 10, 2017

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.

@snikch

This comment has been minimized.

Show comment
Hide comment
@snikch

snikch Aug 10, 2017

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

snikch commented Aug 10, 2017

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

@birjolaxew

This comment has been minimized.

Show comment
Hide comment
@birjolaxew

birjolaxew Aug 10, 2017

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.

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.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

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

mnot commented Aug 10, 2017

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

@daenney

This comment has been minimized.

Show comment
Hide comment
@daenney

daenney Aug 10, 2017

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.

daenney commented Aug 10, 2017

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.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

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.

mnot commented Aug 10, 2017

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.

@daenney

This comment has been minimized.

Show comment
Hide comment
@daenney

daenney Aug 10, 2017

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.

daenney commented Aug 10, 2017

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.

@ryanneufeld

This comment has been minimized.

Show comment
Hide comment
@ryanneufeld

ryanneufeld Aug 10, 2017

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

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

@bradleyfalzon

This comment has been minimized.

Show comment
Hide comment
@bradleyfalzon

bradleyfalzon Aug 10, 2017

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.

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.

@daenney

This comment has been minimized.

Show comment
Hide comment
@daenney

daenney Aug 10, 2017

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.

daenney commented Aug 10, 2017

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.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Aug 10, 2017

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

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

@as

This comment has been minimized.

Show comment
Hide comment
@as

as Aug 10, 2017

Contributor

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.

Contributor

as commented Aug 10, 2017

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.

@sondr3

This comment has been minimized.

Show comment
Hide comment
@sondr3

sondr3 Aug 11, 2017

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 commented Aug 11, 2017

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.

@tyteen4a03

This comment has been minimized.

Show comment
Hide comment
@tyteen4a03

tyteen4a03 Aug 11, 2017

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

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

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 11, 2017

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

mnot commented Aug 11, 2017

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

@sondr3

This comment has been minimized.

Show comment
Hide comment
@sondr3

sondr3 Aug 11, 2017

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.

sondr3 commented Aug 11, 2017

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.

@itsmontoya

This comment has been minimized.

Show comment
Hide comment
@itsmontoya

itsmontoya Aug 11, 2017

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

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

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Aug 11, 2017

  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.
  1. 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?

philipwhiuk commented Aug 11, 2017

  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.
  1. 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?
@szuecs

This comment has been minimized.

Show comment
Hide comment
@szuecs

szuecs Aug 11, 2017

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.

szuecs commented Aug 11, 2017

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.

@SophisticaSean

This comment has been minimized.

Show comment
Hide comment
@SophisticaSean

SophisticaSean Aug 11, 2017

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.

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.

@henhouse

This comment has been minimized.

Show comment
Hide comment
@henhouse

henhouse Aug 11, 2017

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?

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?

@ALTree

This comment has been minimized.

Show comment
Hide comment
@ALTree

ALTree Aug 11, 2017

Member

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.

Member

ALTree commented Aug 11, 2017

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.

@golang golang deleted a comment from Aggamemnon Aug 11, 2017

@golang golang deleted a comment from dwardu89 Aug 11, 2017

@StephanMeijer

This comment has been minimized.

Show comment
Hide comment
@StephanMeijer

StephanMeijer Aug 11, 2017

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

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

@daenney

This comment has been minimized.

Show comment
Hide comment
@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.

@birjolaxew

This comment has been minimized.

Show comment
Hide comment
@birjolaxew

birjolaxew Aug 11, 2017

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

birjolaxew commented Aug 11, 2017

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

@daenney

This comment has been minimized.

Show comment
Hide comment
@daenney

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

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.

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

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.

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

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

@cznic

This comment has been minimized.

Show comment
Hide comment
@cznic

cznic Aug 11, 2017

Contributor

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.

Contributor

cznic commented Aug 11, 2017

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.

@golang golang locked and limited conversation to collaborators Aug 11, 2017

@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Aug 11, 2017

Contributor

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.

Contributor

davecheney commented Aug 11, 2017

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.

@dsymonds

This comment has been minimized.

Show comment
Hide comment
@dsymonds

dsymonds Aug 14, 2017

Member

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

Member

dsymonds commented Aug 14, 2017

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

@ianlancetaylor

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor Mar 7, 2018

Contributor

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

Contributor

ianlancetaylor commented Mar 7, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.