As you've noted yourself, even if it's removed from Go there's nothing stopping anyone from introducing it themselves. 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. A 64bit integer can fit a very big 4 with lots of numbers behind it.Īlso, 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).Ĥ18 is already in use. 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. Why the sudden 🔥 now? What 82 status codes do you expect to need in the 4xx space, even during the lifetime of HTTP?Īside 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.
HTTP ERROR 418 UNUSED CODE
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. I'm all for Easter eggs in headers (effectively infinite space), body content, etc. It's used in plenty of places in the wild, might as well codify it as such. Lets just register it then, instead of going on a campaign against it. The registry is the mechanism we use to coordinate their semantics and assure interoperability, and this status code is not registered.įair enough. Unless there's some RFC that we haven't seen yet? 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. 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. We have a history of people squatting on HTTP status codes, and they're a scarce resource. (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. At the end of the day, I have to say I don't think that tradeoff is worth it. 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. 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). Not trying to sound harsh, but I for one like fun little easter eggs that you find throughout a programming career.
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). Unless I'm reading it incorrectly, the 400 block of HTTP status codes has more than 50 codes available.
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? cc 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. 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. Please consider removing support for 418 from Go HTTP, since it's not a HTTP status code (even by its own definition). 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. 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. Ironically, it's not being used to abuse HTTP itself - people are implementing parts of HTCPCP in their HTTP stacks. HTCPCP was an April 1 joke by Larry to illustrate how people were abusing HTTP in various ways. Note the title - HTCPCP/1.0 is not HTTP/1.x. Its reference is RFC7168, but really came from RFC2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Go HTTP implements the 418 I'm a Teapot status code in go/src/net/http/status.go.
0 kommentar(er)
