> This standard is not meant to define the proper method for brewing tea intended for general consumption, but rather to document a tea brewing procedure where meaningful sensory comparisons can be made. An example of such a test would be a taste-test to establish which blend of teas to choose for a particular brand or basic label in order to maintain a consistent tasting brewed drink from harvest to harvest.
Or more generally shorter seeping time, I've never seen a tea which wanted 6mn seep time, and most somewhat fragile tea want way less (with the possible exclusion of summing the consecutive infusions of an oolong, I guess you do get into the 6mn range total at the end of the session).
"meaningful sensory comparison" can not be made when you literally destroy your tea.
Which is exactly what you're going to do if you steep white or green tea in boiling water for 6mn. You might as well throw the tea into a half-full kitchen bin, wait 6 weeks and lick the bin-juice.
> The protocol has been criticized for omitting any mention of prewarming the pot.[6] Ireland was the only country to object, and objected on technical grounds.[7]
As a fellow brit, my understanding has always been that the tea needs to go into water as close to boiling as possible, and putting the water into a cold pot makes that much harder. Unless in a rush I tend to use the water from pre-heating the pot to also pre-heat the cup so my brew stays hotter longer.
> the tea needs to go into water as close to boiling as possible
Many teas go bad when put in too hot water, green tea comes to mind, but I'm sure there are others as well. These kinds of teas should never be in water that is anywhere near boiling.
As a British expat living in Asia, I was heavily amused to read this passage in Neal Stephenson's The Diamond Age:
There was lengthy discourse between the two men on which of them was more honored to be in the company
of the other, followed by exhaustive discussion of the relative merits of the different teas offered by the proprietors,
whether the leaves were best picked in early or late April, whether the brewing water should be violently boiling as
the pathetic gwailos always did it, or limited to eighty degrees Celsius.
I rarely make tea, but I vaguely remember when I did long ago, that on rare occasions it was bitter and I kind of attributed that to having the water too hot. I assumed it wasn't a problem usually because I wasn't brewing it in a large teapot but after pouring into a mug during which the temperature drops substantially.
While this is cool and funny, the standard claims not to prescribe for general consumption, but to offer a standardised way to brew tea for sensory comparison. Which is great, but the procedure is way too limited:
> 2 grams of tea (measured to ±2% accuracy) per 100 ml boiling water is placed into the pot.
This means 20 grams per liter. That's ridiculously strong tea. 4-8 grams per liter is much more reasonable.
> Freshly boiling water is poured into the pot to within 4–6 mm of the brim. Allow 20 seconds for water to cool.
This is after putting the tea in the pot. But for green tea, you should let the water cool (in the pot or the kettle) before adding it to the tea.
> Brewing time is six minutes.
Again, some teas are better with a different brewing time.
I had an issue a little while ago where I was trying to get iOS's Shortcuts app to post to WordPress. I noticed that doing this seemed to crash every one of my websites within seconds. It was like flicking a switch: I’d run the Shortcuts workflow and seconds later, all of my sites appeared to be offline. This lasted for precisely one hour, after which everything came back online.
Didn't take long to figure out that the sites had actually been online the whole time for everyone else; they were only inaccessible from my local network. At that point, I contacted my host, and they explained that the WordPress component of the Shortcuts app was, for some reason, bombarding the server with a whole lot of requests for files that didn’t exist. The server thought it was under attack and blocked my whole network. Then it got interesting: the guy said that the server was throwing 418s.
I thought he might be mistaken at first. I actually recognized 418, since I've known about the teapot thing for a little while. I asked the guy if it was really the case that the server was blocking my network because it thought my phone was making too many demands for coffee it wasn't capable of producing, and he said that, well, other than the coffee bit, DreamHost really does use 418 for that situation: https://help.dreamhost.com/hc/en-us/articles/215947927-How-d...
That is the only time I've encountered 418 in the wild. That decision seems to be pretty consistent with DreamHost's sense of humor.
This is kind of unfortunate because if they just returned a correct code (429 Too Many Requests), you could have immediately debugged the problem. (The standard suggests also including a Retry-After header, which would tell you when the rate limiting would be lifted so you could try again.)
Basically, there was a machine-readable way to tell you to go away. But instead they told your user agent that they were unable to brew coffee because they are a teapot. What a waste of everyone's time.
Agreed, although the iOS Shortcuts app did not even bother to tell me the server's response; it simply failed, so even if the server had returned a coherent error message, I think I
still would have had to contact support to find out what it said.
I love Shortcuts—it's a great automation tool with some good ideas—but, as is the case with many Apple things, it prioritizes minimalism over functionality. Seems like an odd tradeoff to me, since I think the only people who even know Shortcuts is on their device are people like me who would vastly prefer full-featured complexity—and better documentation—to the smooth, almost toy-like UX.
“Scientists have calculated that the chances of something so patently absurd actually existing are millions to one.
But magicians have calculated that million-to-one chances crop up nine times out of ten.”
In traditional BSD kernels, there is a portable layer and a machine dependent layer. The cpu MD layer for context switching was called cpu_switch(), usually written in assembler. It saved the current state and switched to another. When you regained control of the cpu, you returned from cpu_switch(). There was always somewhere to switch to.
When we added multiple threads per process (part of the KSE effort back in the day), a new low level construct was added - cpu_throw(). You switched somewhere else and threw away your context, didn't put the old thread in the run queue, and never returned. We used this for quickly disposing of threads.
This was all fine, thread implementations, process/thread schedulers, etc came and went.
Somewhere along the way, somebody reused the NetBSD MD/asm layer for one of the powerpc architectures. Of course, NetBSD didn't have cpu_throw(). It was #defined to cpu_switch() because it was close enough and worked.
Until somebody tried to use threading on this powerpc architecture. The fake cpu_throw() didn't prevent a return and the system got far enough to reach the upper machine independent layers and hit the panic.
This caused some amusement. Particularly as somebody had previously suggested that the panic was unnecessary as it cannot happen but I wanted to keep it anyway.
For things that cannot happen, I use error code FFF.
For what it stands for, that comes from a story told by a friend in college whose best friend had done a summer working at a navy shipyard with several salty old mechanics.
Their speech was very liberally sprinkled with the word "fuck".
One day, they got an engine in for repair that was in particularly bad shape. After accessing it, one of the mechanics gave his verdict, and at the same time set a new record for the density of "fuck" in their speech.
Yup. I learned a long time ago that just because its impossible now, doesn't mean there won't be a refactor or something like that and the impossible happens. I still code those checks in precisely because I know they will get thrown.
> I added panic("I'm a teapot!"); to the FreeBSD kernel, many many years ago (sys/kern/kern_thread.c). It was for an impossible, cannot-happen scenario.
I know it’s in jest but I absolutely hate to encounter this kind of thing in the wild. It’s a huge anti pattern and tax you put on other people who have to troubleshoot “impossible” scenarios.
> I know it’s in jest but I absolutely hate to encounter this kind of thing in the wild. It’s a huge anti pattern and tax you put on other people who have to troubleshoot “impossible” scenarios.
These days, getting a phrase you can Google effectively is golden. I don't care if I'm pasting "Ream my holes with a bottle brush, Sir Clyde, for I am going to be late for tea!" as long as it gets me the information I need to fix the problem faster.
That said, maybe something in Latin would be more couth:
Off topic, but first time I've seen "quackable". Hahaha, I like it! I've tried "duck it" earlier, but it just sounds like I'm stuck with auto correct on.
I don't agree. I know some people are opposed to throwing or catching errors for impossible, cannot-happen scenarios, but those scenarios crop up more often than you'd think, and it's useful to have a bizarre but easy to find error message that stands out, rather than something mundane that gets used all over the place.
But it is one more search away. Computer science has more often than not enough inherent complexity to keep one busy. I don't think we need this extra layer of incidental obscurity.
At Cloudflare’s SF office, the conference rooms are all numbered after HTTP status codes. Our Board Room is 404. The coffee shop (Cafe Lambretta) in our building, at the corner of 2nd & Townsend, is bookable in our calendar system as Room 418.
There's a FAANG office which also uses 4xx status codes, but as you would expect, 404 is missing, and 403 is permanently locked (spoiler: it's a door mounted on a wall with nothing behind it). 418, on the other hand, is decorated with whimsical teapots.
> the conference rooms are all numbered after HTTP status codes
Sigh, conference room naming systems! I worked somewhere many years ago where the conference rooms were named after birds of prey: falcon, kestrel, eagle, etc. The smoking room (back in the day) was informally named 'puffin'.
We return 418 on our site in case an admin tries to access the admin panel without a required VPN. It actually clicked pretty fast with everybody on the team, especially those less tech-savvy. They know the "teapot issue" means they forgot to turn on the VPN. It's less confusing than 401/403 :)
The misinformation that 418 brings may be quite helpful if an unauthorized person temporarily gets in hold of your device and tries to access that admin panel.
Some setups are dead simple and require just 1 or 2 clicks to enable a VPN that was registered before, e.g. Tunnelblick on MacOS. The potential hacker who was explicitly told he has to enable a VPN may look for such an app on the compromised computer.
This code has never been officially registered, especially not by that April Fools’ RFC. A number of HTTP implementations added it to their lists of codes anyway; there was a concern that it might create a conflict with if an actual meaning is assigned by the HTTP specification. One of the authors of the specification went around asking libraries to remove the code for this reason. Web developers, like the mature people they are, bullied him into abandoning it.
By the way, if one actually wanted to control coffee pots over HTTP, 400 Bad Request would have been entirely sufficient for this situation. This code has been superfluous from the start. Ironically, it became the very thing it was meant to satirise.
> 400 Bad Request would have been entirely sufficient for this situation.
The whole idea of status codes is that if you encounter one you don’t know about, you can treat it as a member of that family, so any unknown 4xx will be treated the same as a 400. Most of the 400 series is about clarifying what was wrong with the request. 400 just says something’s wrong about the request, but not what. 405 says it’s the method. 406 says it can’t satisfy the provided Accept header. 411 says it wants a Content-Length header. 418 says it’s that you tried to brew coffee in a teapot.
> 418 says it’s that you tried to brew coffee in a teapot.
That you tried to do something so absurdly inappropriate that there isn't even a proper technical way to explain why it was wrong and why it could not work? Like, the server could not even begin to understand what you tried to accomplish with that request.
> That you tried to do something so absurdly inappropriate that there isn't even a proper technical way to explain why it was wrong and why it could not work? Like, the server could not even begin to understand what you tried to accomplish with that request.
The "Blank Stare" response code. Or maybe the "Stunned Stare And Slowly Backing Away" response code.
>> Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.[74] The phrase "Enhance your calm" comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.
Arguably that should be a 5xx response though; there's nothing wrong with the requests, the server just doesn't want to (doesn't have enough resources to) handle them as quickly as they're being issued.
Yup. 500 errors are "the server is broken" (aka the server fails to fulfil the request), 400 errors are "the client did something it should not", including every case of "the client did something the server took issue with for whatever reason".
In fact RFC 6585 added "429 Too Many Requests" specifically for rate-limiting scenarios.
413 (payload too large), 414 (URI too long) or 431 (header fields too large) are likewise things which may technically be valid according to the HTTP spec in general, but which the server rejects.
> Web developers, like the mature people they are, bullied him into abandoning it.
So there is a status code everyone knows is used. The people running the official list know it is used. Now you have a guy running around telling people that they should stop using it because why exactly? Are the people running the list suddenly going to forget that it is in use? Are they going to ignore the issues caused by introducing a status code where the value is already widely misused by existing systems? Are they that intentionally malicious to cause a problem out of spite?
> Web developers, like the mature people they are, bullied him into abandoning it.
As opposed to the guy on a power trip trying to stomp on everyones fun? Grownup people are allowed to have fun, aren't they?
Well we have multiple IP coffee/tea/choc machines and they definitely return 418 codes. Sounds like IANA need to sort out their backwardness and fix things by grandfathering it in for clarity.
HTTP libraries normally use this as their canonical source of status codes that they should have constants (or whatever) defined for.
But 418 I'm a teapot is not in that registry. It’s not clear to me why it wasn’t put in when the registry was established, but it seems most likely that someone made an executive judgement against pointless fun.
To my knowledge, it’s the only status code from an RFC that has not made it into the registry. So many HTTP libraries, perhaps most, have this one exception, an extra status code not from the registry.
In 2017, the httpbis working group chairman Mark Nottingham (mnot) sought to get 418 removed from libraries everywhere (since it wasn’t registered and wasn’t serious); this met with popular resistance (people like their fun) and so he changed direction and sought to have 418 registered properly instead, with https://datatracker.ietf.org/doc/draft-nottingham-thanks-lar.... But that draft was allowed to expire and I’m not sure why.
> But that draft was allowed to expire and I’m not sure why.
Because the current status quo is good enough.
Like in theory, sure, removing 418 makes sense for cleanup purposes. Or barring that, officially registering it.
In practice, it completely does not matter whatsoever. Keeping pointless things out of the registry is fine. And they're not stupid, they're never going to assign 418 to something else, so having 418 in libraries is not going to be an issue. At the end of the day, the current situation is ideal.
If you encounter problems with HTTP 418, you should consider implementing RFC 7168 - The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA). https://tools.ietf.org/html/rfc7168
My school had a class called CS 418 Computer Graphics. One of the final projects was to render a scene reflected off the surface of a teapot STL. I often pondered on the coincidence.
The Utah Teapot is the Hello World of 3D rendering, and a teapot model is included somewhere in almost every 3D rendering application.
I learned about it when I received a copy of BRL-CAD from the Army Research Lab in the mid-90s and it had a teapot, which I thought was quite odd for an application designed for ballistic research.
> A boiling vessel is a water heating system fitted to British armoured fighting vehicles that permits the crew to heat water and cook food by drawing power from the vehicle electrical supply.[1] It is often referred to by crewmembers (not entirely in jest) as the most important piece of equipment in a British armoured vehicle
Tea and coffee pots are everywhere in computer history. This status code. The utah teapot you describe which kicked of 3d rendering and the first webcam was specifically made to film a coffee pot.
I have nginx reply with a 418 page to bad bots requests. Funny easter egg. As a bonus, that makes nginx avoid checking the filesystem for inexistent files, and makes filtering logs easier.
Nginx config snippet:
# Nothing to hack around here, I’m just a teapot:
location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ {
return 418;
}
error_page 418 /418.html;
Nice. I used to use that for all php requests to my websites (like you, I do not have php installed on my servers). Now I just use the nginx 444, which immediately drops the connection.
I wonder if it actually saves much time. Probably not.
"HTCPCP was an April 1 joke by Larry to illustrate how people were abusing HTTP in various ways. Ironically, it's not being used to abuse HTTP itself -- people are implementing parts of HTCPCP in their HTTP stacks." - https://tools.ietf.org/html/rfc2324
I had a coworker who found about 418, found this hilarious and started returning this in case of error.
It made for an interesting troubleshooting session, because at the time, not all browsers would display a meaningful result. Some would return a blank screen - which is easy to find. But not as easy when it was a single call among many others in the page...
Some time ago after realising how GraphQL (don't) use http code, I decided that I wouldn't use http code for business logic like everybody does, but let that responsibility only to the webserver (not auth 401, not found 404, exception 500, and few others). Is that absurd? Should I reconsider going back?
It's not absurd. If you have tuits to spare, strive to be in compliance with the standards to your best ability. Do not just relegate error handling to code you will not touch.
For example, status 422 is used for syntactically correct, but semantically invalid request bodies. Augment your graphql library or application code where appropriate.
That way, you reap the benefits of interoperability. Being in compliance makes you a good Internet citizen in the eyes of your peers.
418 - The status code for a passionate debate! It’s a joke, it’s wrong, it’s funny, it’s right. And finally, oh dear, we need to have a chat about how you prepare your tea. Discussions on the famous 200, 404 and 500 are usually only lukewarm, though 488 stories can get racy.
The original teapot server was an Acorn Archimedes, so this is a nice legacy.
Edit: I misremembered, it was a coffee pot. Bloody barbarians!
From RFC 2324, “
[CBIO] "The Trojan Room Coffee Pot, a (non-technical) biography", Q. Stafford-Fraser, University of Cambridge Computer Lab, <http://www.cl.cam.ac.uk/coffee/qsf/coffee.html>
The longest thread at a hacker space I frequented was fighting over adding a 418 status to the mainline iot kettle stack.
The argument went that a kettle is not a tea pot since before adding a tea bag you can use the hot water for anything, including instant coffee. Someone added a tea bag dunker to the kettle. People started complaining about taking away choice by forcing everyone to use the kettle as a tea pot, so I added a empty tea bag as one of the selections. The argument then went that since it can load empty tea bags it is not a permanent tea pot even though it is mostly a tea pot so it shouldn't include 418 as per RFC 7168.
The last I'd heard of it, they had added peristaltic pumps that can be accessed individually, so if you sent an HTCPCP request to the tea designated pump for coffee it would return 418, but if you sent it to the beverage server it would route your order to the correct pump.
Please if you’re reading this, don’t add this status code and don’t suffer anyone to add this to your code either. It’s not funny, and it’s not clever. Please don’t do it. Find another way to be clever and funny.
Why are you being so disinclusive? Why should tea drinkers be excluded from representation in the corpus of Standards that underlie the fundamental functionality of the Hypertext transfer Protocol driven web?
In fact, you should go brew yourself a cup. You're always kind of a grump til you get a cuppa'.
