13 ms·
Reserve the 418 status code
- joombaga 9y agoWhy is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
- cyphar 9y agoIt's a response to this story (https://news.ycombinator.com/item?id=14987460 https://news.ycombinator.com/item?id=14987460), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code. EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
- endgame 9y agoNote that the "contributor" (Mark Nottingham) is also the author of the document in OP, and deserves a lot of credit for taking this approach. Given that his area of work is HTTP standards, I think he initially started removing 418 to tidy up and make things compliant and isn't just some bore who hates fun. Now he's managed to make everyone happy in a standards-compliant way.
- awirth 9y agoFor those that may not know, Mark is also co-chair of the HTTP Working Group on the IETF[1]. [1]: https://datatracker.ietf.org/wg/httpbis/charter/ https://datatracker.ietf.org/wg/httpbis/charter/
- peterwwillis 9y agoIt's weird though. The origin spec is specifically a discrete protocol called HTCPCP, not HTTP, so it has nothing to do with HTTP standards. They can do whatever they want with 418 in HTTP.
- geofft 9y agoThey can, but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others. It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.
- peterwwillis 9y agoThat's not clear to me. Nobody relies on the feature, it's a tiny piece of code, only some vendors support it, and it's not even part of the spec. (It also can't be reassigned because it was never assigned to begin with) If they like 418, they can add it to the spec. But this idea that it's been "consumed" is weird. It's like saying <blink> was "consumed" in HTML because two browsers used to support it. It was just an unofficial feature of popular vendor software, and is now officially disavowed. Basically what we're saying is we're not going to implement 418 in the spec, but at the same time, we're not going to let anyone use it?
- JoshTriplett 9y ago> It's like saying <blink> was "consumed" in HTML because two browsers used to support it. Which is accurate. Reintroducing a tag named "blink" into HTML to mean something other than "blinking text" would be a really bad idea for compatibility reasons.
- peterwwillis 9y agoSo we're trying to avoid breaking the internet by committing to people expecting an error when they're talking to a teapot? So that past implementations of clients connecting to teapots won't break? Like I say, we could also just add it to the spec... But that would be ridiculous, because why would you support telling someone you were a teapot in an HTTP protocol, when the feature is only useful in a protocol for brewing coffee? That would be like taking a programming language's syntax for assigning data objects and turning it into it's own standard for a text file format. Maybe a time traveler set this whole thing up 19 years ago just to troll people on standards boards.
- toomanybeersies 9y agoIt was interesting reading the threads on /r/webdev about this whole debacle. The threads were full of people saying that he's an arsehole with too much time on his hands who must hate fun. Nobody actually stopped to read the guys bio and realise that he's more than qualified to be bringing up these issues. It doesn't help that the guy who made save418.com is literally 14 (which seems to be about the average age of /r/webdev).
- mystrman111 9y agoThe /r/webdev thread (https://www.reddit.com/r/webdev/comments/6stdcj/http_error_code_418_im_a_teapot_is_about_to_be/ https://www.reddit.com/r/webdev/comments/6stdcj/http_error_c...) remained quite respectful actually, afaik there were no real hostile remarks directed towards Mark Nottingham within it. In fact, it's ironic - the very comment I'm replying to is probably more distasteful and antagonistic than anything that could be found in the Reddit thread.
- LukeShu 9y agoOften reddit threads read more respectful after-the-fact; the less respectful comments either get downvoted enough that they aren't displayed unless you look for them, or are moderated away. Often they are much harsher early in the thread. I'm not sure if that ways the case here, but it is common enough that I wouldn't doubt it.
- mystrman111 9y agoWhen comments are removed by mods on Reddit, they're replaced with the text "[REMOVED]", which doesn't appear once in the referenced thread (insults would not be removed in the first place though, they break no /r/webdev rules). And you can scroll to the bottom of the thread to see all the downvoted comments, none of which are are condescending towards Mark. So no, that isn't the case here.
- pwdisswordfish 9y ago
- habitue 9y agoThe contributor trying to remove 418 and the author of this RFC are the same person (Mark Nottingham[1]) [1] https://en.wikipedia.org/wiki/Mark_Nottingham https://en.wikipedia.org/wiki/Mark_Nottingham
- deleted 9y ago[deleted]
- dsr_ 9y agoBecause: 1st: RFC2324 mentioned it and 2nd: too many people then implemented it.
- lccarrasco 9y agoAn example of an existing easter egg (for reference): https://www.google.com/teapot https://www.google.com/teapot
- LambdaComplex 9y agoI was worried that page would actually return a 200 OK response, but curl confirmed it actually returns a 418 code
- manojlds 9y agoIs there a scenario where people end up there?
- wyldfire 9y agoIt looks as if the teapot is responsive to my phone's gyros. I would've thought it would need special permission for that. What a terribly clever Easter egg.
- HappyTypist 9y agoNope. Actually, there was a paper published recently on using a phone's gyro / accelerometer (through the HTML5 APIs) in order to keylog users; because the API is precise enough for you to detect subtle motion of the phone as you press on the software keyboard. Apparently in some mobile browsers, you can continue to poll the API even when your tab is not on focus.
- HatchedLake721 9y ago
- deleted 9y ago[deleted]
- Izmaki 9y agoIt is implemented as a valid HTTP code in the java Spring framework for everyone to support. That's how I learned about it first.
- x7467 9y agoSame with the standard Go http package (https://golang.org/src/net/http/status.go?s=2540:2600 https://golang.org/src/net/http/status.go?s=2540:2600).
- ericfrederich 9y agohttps://github.com/requests/requests/blob/3c5ecfc9f5f6fd29536a45f8c9f1b54ef637df44/requests/status_codes.py#L55 https://github.com/requests/requests/blob/3c5ecfc9f5f6fd2953...
- masklinn 9y ago> Why is 418 the particular target? Because Mark Nottingham (co-chair of the HTTP WG) first tried to get libraries/stdlibs to remove support for 418 (as part of builtins, since it's not a formally standardised code, he had no issue with application-specific support, everyone is free to return whatever status codes they wish) and faced some pushback, he switched to the alternate tack of getting it into a standard.
- robotmay 9y agoI actually use the 418 code in a simple API we use for IOT devices. I wrote a small program that runs on Raspberry Pis that checks a HTTP endpoint and turns power on and off to a room depending on whether the room is booked out. I wanted a status code on the API that could only possibly be generated on purpose, so if it receives a 418 response it knows to turn off the power; any other response, failure etc turns the power on (so we don't have a room out of use if it breaks). Also it's fun :)
- MatthewWilkes 9y agoWhy check for a special status code, rather than a specific response body, such as a JSON document confirming no use?
- mmmurf 9y ago> a JSON document confirming no use That would be the better design. No need to overload an HTTP status code meant only to indicate transport status.
- robotmay 9y agoHonestly the main reason it works like this is that it was my first foray into Rust, and I found JSON parsing a bit of a pain, whereas matching status codes was very simple. If we expand it to return different options in the future then I'll probably rework it.
- steveklabnik 9y agoInteresting, if you happen to have some time, I'd love to hear about why parsing JSON was a pain.
- robotmay 9y agoLaziness :D I think I was having trouble with string lifecycles due to how I was doing something, and at the time I didn't understand them (I'm still not super sharp on it if I'm honest) and just opted to take an easy way out. Lifecycle notation might be the one bit of Rust I find ugly, actually. I should really revisit this little program at some point, but it's so stupidly simple and works so reliably that I haven't had the inclination to yet.
- bjourne 9y agoI'm somewhat interested in spec writing and legal matters. It seem to me, that this rfc is overly verbose given the change it proposes. And (I think, correct me if I'm wrong) rfc:s are generally supposed to be as short as possible. For example, "IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion." seem like a good idea but is an unrelated matter.
- grandalf 9y agoMany API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response. Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. HTTP is the transport layer, and any application specific scenarios are best handled with a custom error namespace that can be returned within any 2xx HTTP response. Generally speaking, if the HTTP layer is returning 5xx you have a server problem and client code should not know anything about that or do anything but retry. If the HTTP layer is returning 4xx then the client is likely poorly designed or misconfigured. But for typical client operation, when there is no server error or client design/configuration error, HTTP responses should be 2xx or 3xx and any additional detail should be handled in an application-specific way, not by overloading the meaning of HTTP response codes, which are for transport-related concerns only.
- jsiepkes 9y agoWhile I'm inclined to agree with you the makers of SOAP don't seem to share your opinion. Any SOAP fault must be send with an HTTP 500 according to the spec.
- grandalf 9y agoMy take on SOAP's approach is that it isn't overloading HTTP status messages, it's attempting to impose SOAP's message structure on things that are legitimately HTTP 5xx responses, so that the soap client can handle some of those failure modes and the programmer doesn't have to engineer another protocol for dealing with transport errors or parse a different message format. Notably, SOAP is not just doing REST it is attempting to offer an abstraction for dealing with transport issues. Most people designing a REST or rpc style API do not attempt this breadth in their API design, instead they just overload HTTP response codes (from the HTTP and webDAV specs) to handle application-specific stuff, which ends up resulting in the codes being effectively meaningless across applications. SOAP, on the other hand, is meant to be used in the same way across applications. So if your app uses SOAP to consume multiple SOAP APIs, and you engineer failure handling for the HTTP 500 associated with some kind of SOAP fault, chances are you can reuse this logic with all of the SOAP APIs. On the contrary, many REST APIs that overload HTTP statuses do it in some arbitrary way defined by the team working on the API, so the consumer can't make generalizations about the meaning of the error codes in the common cases where one might determine (for example) a retry to be necessary.
- synthmeat 9y agoYeah, I'm sorry, but now we need to standardize BREW HTTP verb. https://tools.ietf.org/html/rfc2324 https://tools.ietf.org/html/rfc2324
- ara24 9y agoWe can never fix the "Referer" header, and we have accepted it! So, why not accept 418 for what it is ? Let it at-least complete its 20th year. HTTP/1.1 418 I'm a Teapot
- api 9y agoOf course nowadays it actually could be a teapot.
- Sonarius 9y agoUnderrated comment right here