Let’s get the AMAs kicked off on Lemmy, shall we.
Almost ten years ago now, I wrote RFC 7168, “Hypertext Coffeepot Control Protocol for Tea Efflux Appliances” which extends HTCPCP to handle tea brewing. Both Coffeepot Control Protocol and the tea-brewing extension are joke Internet Standards, and were released on Apr 1st (1998 and 2014). You may be familiar with HTTP error 418, “I’m a teapot”; this comes from the 1998 standard.
I’m giving a talk on the history of HTTP and HTCPCP at the WeAreDevelopers World Congress in Berlin later this month, and I need an FAQ section; AMA about the Internet and HTTP. Let’s try this out!
You must log in or register to comment.
I loved sharing this with my senior who hadn’t seen it before, and it gave our small team a Ggod chuckle one afternoon. Thanks for your creation.
With the absence of a crystal ball, but with excellent inner knowledge, what future standards could you see being implemented in the next 10 years for internet?
As it turns out, one of the Apr 1st RFCs for this year covers AI Sarcasm Detection, but I can see more serious protocols arising for the transfer of AI model data and/or training procedures in the coming years.
I’d also hope ActivityPub reaches Internet Standard level, though it may fall outside the IETF’s scope of operations.
What’s your take on the fediverse frontier?
I think it’s excellent out here. I was stuck on Reddit for the longest time, and this recent debacle has pushed me to explore the networks at the edge; this feels a lot more like the Internet of old. The analogy of email is apt, I think, with the accounts on multiple servers and the interplay between.
You awaken my nostalgia, curiosity and sense of adventure when you say “explore the networks at the edge”. Are there any other networks than lemmy / mastodon that you would suggest checking out?
Are you tingly anywhere?
Internet Relay Chat’s been one of those things that’s always felt out on the edge. I’ve been on EFnet since perhaps '03, and it’s a lot quieter than it was…
With people moving en masse away from the centralized sites and their Firebase-implemented chats, we may see a pick up in traffic on the IRC networks, which would be good to see.
What are some interesting channels on EFnet? I basically grew up on Foonetic, but moved to Slashnet when #xkcd did. I don’t pay near as much attention to IRC as I used to, but would like to change that
I haven’t been exploring in the depths of EFnet in …many years. I’m confined to the programming-related channels I found in the Way Back When, nowadays: at the moment, #c is probably the most active and it’s almost all old-timers.
Is the internet still kept in Big Ben?
Yes, unless Jen needs to borrow it for a presentation.
I just found out about this on Brodie Robertson’s yt channel! I am not a teapot btw!!
Haha, same here! I was so proud I knew what the title was referring to before reading the post. Lol
Glad to hear it, you should walk around with a HTTP 418 hat so more people know you’re not a teapot.
But then people would think they are a teapot
I have no questions, but I want to let people here know that there are two excellent websites related to this: http.cat and http.dog, for looking up HTTP status codes.
For an example, if http.cat/418 doesn’t brighten your day, I don’t think there’s much that can.
I love this. Thank you so much.
You’re welcome! I try to share this with people whenever I can, hoping that it makes someone’s day better. It certainly gives me a lot of joy when I can respond to something with a relevant http cat, though the few people I do it to might be getting a little annoyed.
What code should be used if we are expecting something to be a teapot? In this scenario it seems a 4XX is inappropriate because there is no error
If you’re writing a TEA-compliant client, you’d send the BREW request and expect a 300 Multiple Options back, whereby the server will tell you which teabags are installed. You’re correct that there’ll be no error, unless all the bag stocks are out server-side.
That’d return 503 Service Unavailable, of course.
A new RFC for IPv7. It’s just IPv4 with an extra octet. Yes or no?
I don’t think the extra address space of IPv6 is the problem holding back its adoption, so “IPv4 with another octet” would likely run into the same issues.
Not that it’s a bad idea, it’s just an idea that’s unlikely to catch on.
What would you say is holding IPv6 back?
The biggest problem IPv6 has is that IPv4 has been so hugely successful: gargantuan resources have been poured into getting the world connected on IPv4, and the routers/etc deployed in the field (especially in sub-Saharan Africa, south Asia, and other places which got the Internet late) are built around version 4: data paths 32 bits wide, ASICs and firmware developed with 4-byte offsets, and so on.
It’s a big effort, and more importantly an expensive effort, to move all that infrastructure over for what the end user perceives as no benefit: their websites load just the same as before.
Are you saying there’s no financial incentive at the individual level to upgrade?
Essentially. If the end user is being asked to make a financial outlay to get to the same things they did before, it’s unlikely that will go down well.
You can unilaterally create another status code. What do you create?
Wasn’t there a new HTTP action recently proposed for “This is a JSON RPC request that we’ve convinced ourselves is actually REST and we’ve been using POST and someone finally pointed out that that was stupid”?
Not a new status code but still vaguely amusing.
I quite like the idea of HTTP 256 Binary Data Follows, which is just 200 OK but you asked for a non-text content type file.
I’m actually going to that conference! What’s the title of your talk? I’ll be sure to attend it!
Excellent. I’m on Stage 4 on the Thursday afternoon: “Brewing Tea Over The Internet”.
Should be fun times, see you there.
What’s the funniest legitimate non-joke standardization detail you’ve come across?
I enjoy that the original draft for the Referer header spelled it wrong, and now we’re all stuck with the typo forever…
I’d be happy if we’d just accepted “referer” as the correct spelling for everything, but instead we have the “Referrer-Policy” header, so now I need to check the correct spelling for anything involving referring…
I do sort of like the idea that because we want to keep backwards compatibility on software we just change the language instead since that’s easier.
Can someone elaborate on this please?
Edit: oh jeez. I’m so used to reading “referer” I didn’t even realize it was a typo.
What other such joke standards (by you or others) do you like?
A little lower down the stack, I always liked the Evil Bit in TCP, a standard which removes all need for firewalls heuristics by requiring malware or packets with evil intent to set the Evil Bit. The receiver can simply drop packets with the Evil Bit set, and thus be entirely safe forever from bad traffic.
At the physical interface layer where data meets real life, I especially enjoy IP over Avian Carrier; that link in particular is to the QoS definition which extends the original spec for carrying packets by carrier pigeon.
Wow. Never knew about these :)
The Evil Bit sounds like the real Do Not Track header field
Someone tested the evil bit and found a selection of real-world networks that react to its presence
Fun read, thanks for the link!
With the advances on SDcards, IPoAC is getting better and better.
As the saying goes, “for bandwidth, nothing beats a truck full of
tapes1TB MicroSDs hurtling down the highway”.
Do you regret adding it, or with the knowledge you have today, would you still add the 418?
Since a bunch of languages have not implemented it, or/and has long discussions about it:
https://github.com/dotnet/runtime/issues/15650
https://github.com/golang/go/issues/21326
https://github.com/nodejs/node/issues/14644
https://github.com/psf/requests/issues/4238
https://github.com/aspnet/HttpAbstractions/issues/915Sheesh, some people have no sense of humour.
Personally I don’t have any problems with it (if that was directed at me) - I’ve added 418 as “unhandled exception code” response to a bunch of applications, so I can easily differentiate whether my application is throwing an error, or whether it’s some middleware gateway AWS io-thing
I was just curious what OP thought about it, since in the early days it wasn’t uncommon to add goofs or easter-eggs into software, but nowadays not done so much… and apparently the “HTTP Working Group” doesn’t like it either… So I was curious whether OP though in hindsight whether it should’ve been added or not
How can it be unhandled? It’s right there in the song, just before the spout!
You’d have to catch up with Mr Masinter to get his opinion on adding error 418, I’m afraid; that piece of the business wasn’t my work.
I’m happy it’s there though: it may have sparked flamewars, but at this point what hasn’t. It does bring somewhat of that sense of humanity to the whole enterprise of working on the Internet.
I remember when I first learned of error 418 and it did really help me understand that the Internet as we know it was made and shaped by regular people with senses of humor. Helped make it seem a bit less daunting/intimidating to understand.
It reminds me of how the Network Port 666 is specifically reserved for doom, always love Easter eggs like that in officially used protocols.
I’m just finding out about this trivia now but I’m a big fan
I remember when I learned about this, I was working on an absurdly large project on my own. I was lost in all the details and losing hope of ever finishing. I was working on the backend API when I learned of this and took the time to implement the 418 response. It felt silly and brought the fun back to the project.
Thank you for fixing a critical flaw in the original RFC.
What did you think about the Save 418 Movement? Were you involved in it in any way?
My endorsement is at the bottom of that page, in fact. I wasn’t an active campaigner, but a word in favor was the least I could do.
Oops, RTFM. Well, thanks for fighting the good fight with the power of your reputation.
Every once and a while I’d just like to see 200 get some love, but no. It’s all 404 this, 502 that.
I’m just “OK”. It’s like being the middle child of response codes.
username checks out
200 is probably the most common status no? Many successful responses will give 200 in the backend
OK
Was RFC 7168 written with Captain Picard’s tea Earl Gray, hot in mind? If not, are follow up modifications planned?
So replicators are kind of a special case: they can make anything already fully prepared, without the need for a brewing command to be sent. It’s possible that by the 24th century, there’s a compatibility layer between Replicator Intermediate Language and HTCPCP, but I’ll leave that to future generations to establish.
