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?
Re:HTTP 418 I'm a Teapot
by petee on Tuesday July 31, 2018 @10:16AM
(#17653291)
And don't forget the new extension - HTCPCP-TEA:
> TEA-capable pots that are not provisioned to brew coffee may return either a status code of 503, indicating temporary unavailability of coffee, or a code of 418 as defined in the base HTCPCP specification to denote a more permanent indication that the pot is a teapot.
Re:HTTP 418 I'm a Teapot
by WorldMaker on Tuesday July 31, 2018 @12:43PM
(#17654674)
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. ;)
Re:HTTP 418 I'm a Teapot
by WorldMaker on Wednesday August 01, 2018 @03:17PM
(#17665972)
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.
I read your link to the RFC before I read the Mozilla article. It was not clear that the RFC was an April fools joke until after I read the Mozilla bit that highlighted it being a gag. After that, the date at the top of the RFC became obvious.
Is the date in the status code itself? If the authors were American, then they would write the 1st of April 1998 as 4/1/1998, which could be truncated to 4/1/8.
Re:HTTP 418 I'm a Teapot
by poizan42 on Tuesday July 31, 2018 @10:00AM
(#17653160)
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?
Re:HTTP 418 I'm a Teapot
by zaarn on Tuesday July 31, 2018 @10:17AM
(#17653303)
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)
Re:HTTP 418 I'm a Teapot
by derefr on Tuesday July 31, 2018 @10:19AM
(#17653325)
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.
Re:HTTP 418 I'm a Teapot
by linker3000 on Tuesday July 31, 2018 @10:27AM
(#17653398)
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.
Re:HTTP 418 I'm a Teapot
by derefr on Tuesday July 31, 2018 @10:38AM
(#17653502)
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.
Re:HTTP 418 I'm a Teapot
by petee on Tuesday July 31, 2018 @10:30AM
(#17653429)
The protocol itself says what you should be speaking: "I'm a teapot. Talk to me in Teapot, not Coffee." -- anything other than a teapot responding with a 418 would be RFC non-compliant
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?
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".
> TEA-capable pots that are not provisioned to brew coffee may return either a status code of 503, indicating temporary unavailability of coffee, or a code of 418 as defined in the base HTCPCP specification to denote a more permanent indication that the pot is a teapot.
https://tools.ietf.org/html/rfc7168
So, all HTTP-only implementations that have 418 are technically incorrect, since it is not part of HTTP.
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
I read your link to the RFC before I read the Mozilla article. It was not clear that the RFC was an April fools joke until after I read the Mozilla bit that highlighted it being a gag. After that, the date at the top of the RFC became obvious.
Third sentence probably should have been a warning flag. I think nearly every paragraph has word play
So it likely treated it like a bad host header.
https://unix.stackexchange.com/questions/405783/why-does-man...
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.
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.
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.
TL;DR is that the standard is used for the most consistent tea, not most tasty/enjoyable tea
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.
On what grounds is someone blocking DefCad's website?
And this is why: https://www.attorneygeneral.gov/taking-action/press-releases...
https://tools.ietf.org/html/rfc7725
451 Unavailable For Legal Reasons
> This status code indicates that the server is denying access to the resource as a consequence of a legal demand.
Previous discussion: https://news.ycombinator.com/item?id=14987460
[1] http://save418.com/