
HTTP 418 I'm a Teapot - serenesravan
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418
======
petee
Seems an odd link to choose...considering how old this is, why not just post
the RFC instead?

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

While we're on the subject though, I'm in early planning for a replacement
controller for my Keurig 250 (if I were using a RPi, I'd call it the Pig 250,
but it'll likely be a different board) -- I'm excited to actually get HTCPCP
in something real; thoughts on practical implementation?

~~~
JeanSebTr
Oh! I never took the time to read it and didn't knew the protocol was actually
for coffee machines.

It makes sense to have the 418 status code then.

> Any attempt to brew coffee with a teapot should result in the error code
> "418 I'm a teapot".

~~~
hoppelhase
Indeed. It defines code 418 for HTCPCP (which is an extension to HTTP), not
HTTP itself.

So, all HTTP-only implementations that have 418 are technically incorrect,
since it is not part of HTTP.

~~~
WorldMaker
Most of the codes defined in the WebDAV standard are assumed by most
implementations and also to an extent by IETF's standardization efforts to be
recognizable HTTP codes even in non-WebDAV situation. Those codes are only
defined semantically in the WebDAV protocol, but they are considered broadly
to be extended HTTP codes available for general usage as defined, simply with
less defined semantics in those cases.

Which would seem to apply equally here: While the HTCPCP standard only
indicates the semantics of the codes with respect to usage in HTCPCP
scenarios, they are still code extensions to HTTP and available for use as
defined, simply with fewer specified semantics.

Which is to say if you build your HTTP REST API using 418, we can all
generally agree that the error from your API at that time is "I'm a teapot".
Given that you aren't an HTCPCP endpoint, we just can't assume that we could
then try HTCPCP-TEA to then try to brew tea, as we can't be sure that the
semantics follow. Perhaps your REST API is simply a catalog of brewing
equipment for purchase, and it still makes sense for some of your endpoints to
fail with a 418. :)

It's unlikely for the IETF to assign 418 to a different HTTP-based or HTTP-
like protocol with an entirely different and non-compatible definition, so
even if 418 is laxly defined for HTTP proper, it's still "technically correct"
in the sense that you can technically use it all you want and the only
repercussions from the technical specs are if you implement it wrong in
HTCPCP, there's no wrong way to use 418 in plain HTTP. ;)

[https://http.cat/418](https://http.cat/418)

~~~
hoppelhase
I was not arguing against implementing 418. IMHO, it's okay to implement it
since it won't be assigned to something else.

~~~
WorldMaker
Sure, that's fair, I was simply pointing out that the web is a much more
complicated mixture of its standards documents than just surface level, to the
point where originally intended to be unrelated standards do bleed together.
April Fools Joke or not, "HTCPCP" or not, 418 is an interesting part of HTTP's
legacy now.

------
molf
I'm reminded of this NPM issue:
[https://github.com/npm/npm/issues/20791](https://github.com/npm/npm/issues/20791)

~~~
poizan42
I don't understand how this happened. Why would a client appending the port in
the Host: header result in the server giving that reply? Is it a default joke
reply if the npm repository server is confused?

~~~
zaarn
Most likely it was the server being very confused and not understanding that
you could put the port in the Host header (very legit thing to do and proxies
do it a lot)

So it likely treated it like a bad host header.

------
davidkuhta
Reminds me of:

[https://unix.stackexchange.com/questions/405783/why-does-
man...](https://unix.stackexchange.com/questions/405783/why-does-man-print-
gimme-gimme-gimme-at-0030)

------
derefr
I still say 418 is a sensible error code to use to inform clients who try to
spew HTTP at non-HTTP ports that they’re barking up the wrong tree.

I.e.: “I’m not a web server, bro. I’m a teapot.”

You could theoretically further provide a Protocol header in the response
(like the one in the request for an HTTP upgrade) that says what protocol you
_should_ be speaking on that port.

~~~
linker3000
Helpful! That would sure narrow down the number of possible vulnerabilities
that had to be tried and would help a script kiddie breeze through the probing
much faster.

~~~
derefr
I’m thinking in IPv6 terms here, where each separate “service” is exposed on a
separate IP, and the only time you get multiple ports open on a single IP is
when it’s one daemon that is holding multiple ports open in order to allow
clients to speak one of several protocols to it (i.e. using TCP/UDP ports for
their original purpose of layer-4 negotiation of the layer-{5,6} protocol
stack you’ll be speaking the same layer-7 protocol over.)

In such cases, you can probably recognize the server just from the set of
ports that are open (e.g. a Slack server instance: HTTPS, XMPP, IRC.) So the
server pointing out that you’re speaking to the wrong one of its ports with
your message, in the way a client can understand, won’t really impact your
attack surface.

Of course, if the world really did adopt “the IPv6 port usage paradigm”, and
did away with NATs and other things that map ports to other ports, there’d be
little need for this: a destination port would be a 1:1 identifier for a
protocol, and you could know you were speaking “the wrong protocol” to a port
simply by looking at what port it is! Network client libraries could get away
with simply not letting you specify both the port and the protocol, instead
only leaving one configurable and deriving the other one from it.

But we’re a long way off from that, and I would think that for now, being able
to “permanent fail” HTTP clients off of infinitely retrying some internal
service port exposed on your k8s-mesh load balancer, would be useful.

~~~
sirsuki
> I’m thinking in IPv6 terms here

You do realize that the utopian future you dream of will never happen!

There is too much money to be had hording and selling IPv4 addresses.

------
scratchfi
At least we know the only correct way to brew tea.
[https://en.wikipedia.org/wiki/ISO_3103](https://en.wikipedia.org/wiki/ISO_3103)

~~~
mrguyorama
An elaboration by Tom Scott:
[https://www.youtube.com/watch?v=nAsrsMPftOI](https://www.youtube.com/watch?v=nAsrsMPftOI)

TL;DR is that the standard is used for the most _consistent_ tea, not most
_tasty /enjoyable_ tea

------
Mizza
Sort of related:

I'm in Pennsylvania, and I currently get a "451" error code when visiting the
DefCad website. I've never seen in the wild before. A bit scary.

~~~
ancarda
What? Can you post the full error message (HTML/text?)

On what grounds is someone blocking DefCad's website?

~~~
Mizza
This is what the response looks like (I added it to Wikipedia):
[https://en.wikipedia.org/wiki/HTTP_451#/media/File:Status_co...](https://en.wikipedia.org/wiki/HTTP_451#/media/File:Status_code_451_example.png)

And this is why: [https://www.attorneygeneral.gov/taking-action/press-
releases...](https://www.attorneygeneral.gov/taking-action/press-
releases/attorney-general-shapiro-governor-wolf-state-police-successfully-
block-access-to-3d-downloadable-guns-in-pennsylvania/)

~~~
jacob019
"the company agreed to block Pennsylvania users from its site" If it was being
blocked at the ISP level, then I would be concerned.

------
gregmac
For the record, despite proposals to remove it, node.js, ASP.NET and Go have
all decided to keep it in [1].

Previous discussion:
[https://news.ycombinator.com/item?id=14987460](https://news.ycombinator.com/item?id=14987460)

[1] [http://save418.com/](http://save418.com/)

------
scratchfi
At least the correct way to brew tea is known.
[https://en.wikipedia.org/wiki/ISO_3103](https://en.wikipedia.org/wiki/ISO_3103)

------
jwr
I still remember this April Fool's joke. I feel old now. :-)

------
jwilk
Related:
[https://news.ycombinator.com/item?id=15004907](https://news.ycombinator.com/item?id=15004907)

------
Izmaki
I've supported this error code in at least three production systems. Am I
doing it right? _hmm_

------
zaarn
Mozilla should consider having the wiki return a 418 on this page...

------
cremp
Obligatory Google:
[https://www.google.com/teapot](https://www.google.com/teapot)

