
Reserve the 418 status code - BenjaminCoe
https://tools.ietf.org/id/draft-nottingham-thanks-larry-00.html
======
robotmay
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 power on (so we don't have a room out of
use if it breaks).

Also it's fun :)

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

~~~
mholmes680
I solved this with a WeMo plug, which gives me an app and alexa control. Used
for electric hair iron of wife, and coffee pot as backup plan with timeout
setting, and also saving us driving back home for the "did you unplug the
iron" moments.

Both appliances actually have their own auto-off, but I like redundancy.

~~~
marksomnian
But does it respond to HTCPCP?

------
joombaga
Why 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) :)

~~~
lccarrasco
An example of an existing easter egg (for reference):
[https://www.google.com/teapot](https://www.google.com/teapot)

~~~
manojlds
Is there a scenario where people end up there?

~~~
Benjammer
Yes, ^this^ one.

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

~~~
marrs

        Many developers use 4xx status codes to indicate things
        like data validation errors or other things that are not
        part of the HTTP transport.
    

You mean like a form validation error? Surely an invalid request is a bad
request. No?

~~~
grandalf
> Surely an invalid request is a bad request.

Invalid to whom? Should a form submitted with a username that already exists
in the system get a 500 response code? What's the server error?

~~~
nulagrithom
I'd go with 409 Conflict, but I'd also accept 400 Bad Request

Incidentally, the RFC for 409 makes it quite clear that this touches the
application layer:

> Conflicts are most likely to occur in response to a PUT request. For
> example, if versioning were being used and the representation being PUT
> included changes to a resource that conflict with those made by an earlier
> (third-party) request, the origin server might use a 409 response to
> indicate that it can't complete the request. In this case, the response
> representation would likely contain information useful for merging the
> differences based on the revision history.

[https://tools.ietf.org/html/rfc7231#section-6.5.8](https://tools.ietf.org/html/rfc7231#section-6.5.8)

In any case, getting pedantic about what's "an error" and using 200 OK for
everything that didn't fail at the transport layer is a super frustrating
experience regardless of whether or not it's semantically correct. Please
don't do that to consumers of your API.

~~~
grandalf
Versioning a resource, per WebDAV is a very specific application.

> using 200 OK for everything that didn't fail at the transport layer is a
> super frustrating experience regardless of whether or not it's semantically
> correct

The semantics of my application's protocol do not necessarily mirror the
semantics of HTTP, nor are the descriptive statuses semantically similar,
since most HTTP statuses are simply about transport (even though a few touch
on the "application" of URIs as resources).

~~~
nulagrithom
There's no mention of WebDAV in that RFC.

Would it kill you to send back a 400 status code upon an error? Having to
check for { isError: true } or something similar is obnoxious. I don't see the
value gain of responding 200 OK when the operation was not successful.

~~~
grandalf
> when the operation was not successful.

Well, do you care about all the successful and unsuccessful aspects of TCP
that underlie the connection? No, you just care that it was successful,
allowing the HTTP request. Assuming that is successful, then your API
"operation" can occur and return its result.

------
ara24
We 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

------
synthmeat
Yeah, I'm sorry, but now we need to standardize BREW HTTP verb.

[https://tools.ietf.org/html/rfc2324](https://tools.ietf.org/html/rfc2324)

------
bjourne
I'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.

------
api
Of course nowadays it actually _could_ be a teapot.

~~~
Sonarius
Underrated comment right here

