Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reserve the 418 status code

tools.ietf.org

Post reply on HN
Print view View original

51–60 of 124 posts

Re: Reserve the 418 status code

#51

Post by pwdisswordfish »

vacri wrote: post #29
peterwwillis wrote: post #16

Earlier quoted context omitted.

So 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 bre…

It's a miniscule bit of humour that consumes 1 of 31 used slots in a 100-slot block, in an area of tech that isn't even remotely drowning in 'fun stuff'. What does it really matter? There are plenty of perfectly serious RFCs that are even less implemented than 418. It's not like this RFC ratifying a 20-year-old joke that 'made it' is going to generate a cavalcade of lookalikes.

You never know. Some people used to think 4 billion slots would be more than enough for addressing every host in the world, and so they allocated the addresses haphazardly. Now look at the sorry state of IPv6 adoption 20 years after it's been designed.

Some people used to think 65536 code points would be more than enough to encode every character in every language. Later it turned out not to be the case. Expanding that space necessitated the creation of hacks of various degrees of awfulness like UTF-16, CESU-8, WTF-8; today nearly every Unicode-aware environment has to be prepared to deal with unpaired surrogates somehow.

Expanding a fixed-size namespace is a pain. Who knows if HTTP status codes won't become scarce some day. They better not be wasted on frivolities.

Re: Reserve the 418 status code

#52

Post by fest »

jacquesm wrote: post #35
HappyTypist wrote: post #31

Earlier quoted context omitted.

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

Oh, that's really nice. So if you have a fix (and even if you don't) you can use dead reckoning and tie any points where the GPS is accessible and then re-create the path the phone took. That's a bit of a leak. Wonder how long after or before a GPS fix this would be effective, those phone accelerometers probably aren't all that accurate but you might be able to calibrate the one in a specific phone if you have data a…

Even using calibrated and temperature controlled consumer level accel/gyro sensors for dead reckoning results in estimated velocity error reaching few meters/s in a second or two.

Current consumer level sensor quality is enough for: a) attitude estimation; b) smooth interpolation between GPS updates if they arrive often enough;

Re: Reserve the 418 status code

#53

Post by MatthewWilkes »

robotmay wrote: post #41

I 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…

Why check for a special status code, rather than a specific response body, such as a JSON document confirming no use?

Re: Reserve the 418 status code

#54

Post by grandalf »

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

Re: Reserve the 418 status code

#55

Post by mmmurf »

MatthewWilkes wrote: post #53
robotmay wrote: post #41

I 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…

Why check for a special status code, rather than a specific response body, such as a JSON document confirming no use?

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

Re: Reserve the 418 status code

#56

Post by michaelmior »

robotmay wrote: post #41

I 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…

I was hoping for a minute that the IOT device was a connected teapot...

Re: Reserve the 418 status code

#57

Post by quuquuquu »

pwdisswordfish wrote: post #51
vacri wrote: post #29

Earlier quoted context omitted.

It's a miniscule bit of humour that consumes 1 of 31 used slots in a 100-slot block, in an area of tech that isn't even remotely drowning in 'fun stuff'. What does it really matter? There are plenty of perfectly serious RFCs that are even less implemented than 418. It's not like this RFC ratifying a 20-year-old joke that 'made it' is going to generate a cavalcade of lookalikes.

You never know. Some people used to think 4 billion slots would be more than enough for addressing every host in the world, and so they allocated the addresses haphazardly. Now look at the sorry state of IPv6 adoption 20 years after it's been designed. Some people used to think 65536 code points would be more than enough to encode every character in every language. Later it turned out not to be the case. Expanding th…

As frivolous as you think 418 is, people use it.

You honestly can't, in this situation, be the judge of what is "frivolous use" and what is not.

Re: Reserve the 418 status code

#58

Post by robotmay »

michaelmior wrote: post #56
robotmay wrote: post #41

I 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…

I was hoping for a minute that the IOT device was a connected teapot...

Unfortunately my flat is too small for me to justify a networked kettle...yet ;)

Re: Reserve the 418 status code

#59

Post by jsiepkes »

grandalf wrote: post #54

Many 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 a…

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

Re: Reserve the 418 status code

#60

Post by robotmay »

mmmurf wrote: post #55
MatthewWilkes wrote: post #53

Earlier quoted context omitted.

Why check for a special status code, rather than a specific response body, such as a JSON document confirming no use?

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

Honestly 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.
Post reply on HN