Hacker News Reader

Comment by daveslash | Hacker News Reader

For those who may not know, this comes from RFC 2324: ""Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0), The RFC was published 1 April 1998 (April Fool's Day). There's a long history of humorous RFCs published on 1 April. For example, RFC 1149 "IP over Avian Carriers" https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

List of Additional April Fool's RFCs https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...

View on HN

To toot my own horn, I did an April Fool’s status code RFC: 397 Tolerating, for when a client sends a flawed request, but you’re going to tolerate it because you know what they really meant:

https://pastebin.com/TPj9RwuZ

Is this basically "I'm doing the robustness principle but also communicating that I'm judging you"?

I love the concept.

At the firm I work at, one of my "10% time" projects was to build out a "warnings" field in the API response. There are often times that you want to say "this is not inherently wrong, but likely represents wrong assumptions upstream" or "you're asking for something that's obsolete and is now being silently ignored".

For example, if someone passes a currency field with the wrong number of decimal places. You might actually want to say your product costs $1.62346, but it's more likely you're not sanitizing your data and relying on non-guaranteed rounding behaviour to make it right.

The problem we have is that the most of the API fields are opt-in-- the people who could most use the warnings are unlikely to go in and activate them.

To be honest I think the robustness principle isn’t very well supported. We shouldn’t be this accommodating in what we accept. We’re very likely harming users by ignoring errors.

That said we should be much more accommodating in our user interfaces to help prevent this kind of crap data.

lol Pretty much! It cites the Robustness Principle.

That’s what I get for responding while eating dinner and not reading thoroughly lol

April Fools RFCs are part of the "Independent Stream", which mean the top left would say "Independent Submission", not IETF. Also, Informational, not Standards Track. Just FYI :)

This is a good idea for APIs that allow you to update an object by sending a partial JSON object with the keys you want to update, when technically you’re supposed to send the entire updated object representation unless JSON Patch is being used.

Alternatively there actually is a HTTP PATCH verb that you can use for this - I think that tolerating is more appropriate for common misspellinks - i.e. accepting a request like an HTTP POST {"days": 12, "horus": 13 "minutes": 27}

But what happens when the API is updated to support Egyptian gods as keys?

You submit a scarab report.

I still love that people actually went through the effort to "implement" it.

Any links to APIs that implement a 418 HTTP response code?

If I have anything to do with it, there is a 418 response hidden somewhere.

I recall a few internal projects at a previous employer would return 418 if the user managed to royally mess something up as a "wtf, how are you here?!" kind of response.

I feel like I am not alone in implementing 'weird' HTTP codes when I get bored / as an easter egg. Pretty sure I also used HTTP 420 at least once.

Unlike 418 I'm a Teapot, 420 Enhance Your Calm is actually a nonstandard HTTP status code. The correct response is 429 Too Many Requests. [1]

[1]: https://datatracker.ietf.org/doc/html/rfc6585#section-4

Ah, the good ol' 420 - EnhanceYourCalm

“Uhh ummm no” -code reviewer

Yeah, code reviews definitely killed some of the fun in coding, they are rarely performed with humor.

I generally make it a goal to have a test case with silly enough data to get a comment from a reviewer.

I remember reviewing a really long document (> 50 pages) that had in one bullet list the phrase 'Marks and Spencer tandoori chicken sandwich'. The doc was otherwise camera ready and the phrase was obviously there to see if I was in fact reading it

https://www.google.com/teapot

I added the 418 response code to my gopher server [1]. There was one web bot that constantly hit it and was clueless that it wasn't a web server. It finally got a clue.

[1] https://github.com/spc476/port70

Binance API (i.e https://api.binance.com/api/v3/ticker/price) does it when there are too many requests from one IP (I assume that's the reason). They could have used something else like 429 but for some obscur reasons they're using 418 (if anyone knows the actual reason...).

It will happen often if you try to make a call to their API through Google sheet scripts.

Http.cat implements it: https://http.cat/418

.Net seems to have it: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnet...

http.StatusTeapot in Go: https://pkg.go.dev/net/http#pkg-constants

4k+ results on Github: https://github.com/search?utf8=&q=http.StatusTeapot&type=Cod...; ~600 excluding _test.go files: https://github.com/search?q=http.StatusTeapot+-filename%3A*_...

I sometimes return a 418 when request heuristics detect bad behavior that looks intentional. I don’t document it, though.

No link but our internal API for mobile apps returns a 418 if the installed version is too old.

If you have an IoT teapot, when do you return it?

From the docs:

> ... indicates that the server refuses to brew coffee because it is, permanently, a teapot.

So I guess, when it is asked to perform coffee brewing? But pay close attention, to your general purpose brewer:

> A combined coffee/tea pot that is temporarily out of coffee should instead return 503.

I'm shocked nobody's posted it yet, but iiNet (Australian ISP)'s coffee cam[0] is 13+ years running now:

https://coffeecam.iinet.net.au/coffee/

Reply on news.ycombinator.com