Interesting Facts About Http Error Messages

6 minutes read
crafted by , on 28 May, 2015, in

Your production server goes down, you scramble to find out why, and you find out the the server is reporting ‘HTTP 418 I’m a teapot’ error when accessing it. Puzzled, you learn about the humour behind HTTP protocols.

As we’re also using Monitive to monitor our own services and some external ones, we sometimes stumble upon strange situations and issues. I thought about using some other external service, but then I remembered about the “eat your own dogfood” philosophy and decided to deploy a completely separated instance of Monitive that will do just one thing: monitor Monitive. After all, a lot of users are trusting us to let them know when their sites have issues, and it seemed very important to us to find out if something is up (or down).

Everything was nice and lovely until a few days ago when I received a weird SMS outage alert. And the weirdness came not from the alert itself, but from the reason of the outage: Server returned 418 I’m a teapot. Say what? Teapot? That’s at least funny if not weird at the same time.

So I’ve looked this up. It seems that back in 1998, some dude Larry Masinter decided to make an April 1st prank by submitting a RFC to document HTTP 418 code. Funny enough, it looks that there are some server implementing it, and it’s even funnier that in 2014, some other dude Imran Nazar decided to extend the HTCPCP protocol, because the original protocol back in 1998 was only able to handle coffee requests, and Imran wanted it to be able to handle tea requests.

Here’s an excerpt of the original protocol:

L. Masinter
1 April 1998

Network Working Group
Request for Comments: 2324
Category: Informational

Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.

1. Rationale and Scope

There is coffee all over the world. Increasingly, in a world in which computing is ubiquitous, the computists want to make coffee. Coffee brewing is an art, but the distributed intelligence of the web-connected world transcends art. Thus, there is a strong, dark, rich requirement for a protocol designed espressoly for the brewing of coffee. Coffee is brewed using coffee pots. Networked coffee pots require a control protocol if they are to be controlled.

Increasingly, home and consumer devices are being connected to the Internet. Early networking experiments demonstrated vending devices connected to the Internet for status monitoring [COKE]. One of the first remotely _operated_ machine to be hooked up to the Internet, the Internet Toaster, (controlled via SNMP) was debuted in 1990 [RFC2235].

The demand for ubiquitous appliance connectivity that is causing the consumption of the IPv4 address space. Consumers want remote control of devices such as coffee pots so that they may wake up to freshly brewed coffee, or cause coffee to be prepared at a precise time after the completion of dinner preparations.

You can read the entire RFC here. It’s pretty well documented, and enjoyable to read (if you know what GET, POST, PUT and DELETE operations are).

Now how’s that for something really funny when it comes to TCP/IP protocols?

So basically, regarding the 418 I’m a teapot error, this error should be signaled whenever someone tries to brew coffee by using a teapot instead of the designated coffee-pot.

The fun doesn’t stop here. There are several other protocols that you might be humored to learn about: “the evil bit” and “IP over burrito”.

RFC 3514 – The Security Flag in the IPv4 Header

Some guys thought the people are going through tremendous efforts to keep the internet safe by analysing all the packets, heuristically, by source, destination, etc. There are even teams and companies that are specialized in security. So why go to all this trouble when RFC 3514 found a really simple way to fix this:

1. Introduction

Firewalls [CBR03], packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. The problem is that making such determinations is hard. To solve this problem, we define a security flag, known as the “evil” bit, in the IPv4 [RFC791] header. Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1.

I mean, why didn’t we think of that, right?!

IP over burrito

Now this one is really crazy. At first it looks like complete madness, but then it starts to make sense as it makes a parallel between a standard Internet Header format and a burrito.

Here’s a small excerpt of the IP over Burrito Carriers draft:

INTERNET-DRAFT
IP over Burrito Carriers
April 2005

Abstract

IP over Burrito Carriers describes an experimental method for the creation of edible data packets. This standard is intended to be implemented in metropolitan area networks due to the preexisting burrito delivery infrastructure. While currently only flour tortillas have been found acceptable for encapsulating the data contained in the packet, tests are underway to determine the viability of using corn tortillas. One must be wary of disreputable IP over Burrito service providers as packet corruption and bad data handling can result in damage to the receiving unit and may result in an extremely messy packet rejection. Conveniently, there is a rating system already in place. While the rating by the health department doesn’t ensure proper data encapsulation, it does allow the end user to determine if the service provider’s quality to cost ratio is adequate. This is an experimental standard, not a recommended standard.

Introduction

In today’s wireless hotspot, WAP enabled, WiFi zoned world of dining there exists a discrimination against diners who prefer to eat outside the established confines of the restaurant. The IP over Burrito standard was developed to create an edible solution to the growing rift in the availability of free internet access between sit-down and delivery/carryout dinners. While considerable research has yet to be performed on the IP over Burrito standard, multiple simulations in a controlled environment have proven to be both successful and filling. Some concerns that must be addressed in the future include the ability of the hosts buffer to accommodate a large number of packets while they are processed. Also the fact that a buffer overflow would cause a catastrophic system failure resulting in a purging of all previously processed datagrams is of major concern. Currently datagrams are encapsulated in a flour tortilla. Future projects will determine the viability of using corn tortillas but for now the standard requires the use of a flour tortilla for all datagram encapsulation.

Schulze, Lohsen

Read the entire RFC draft here.

Why oh why?

Going beyond posts with cats and babies, the Internet is a really technical world, with countless routers, gateways, backbones, a thousands of devices that keep everything in shape and make it possible.

I find that this kind of humour, from time to time, is welcome, since the job of a network engineer is usually not a truckload of fun. All those protocols and packets could use some sugar sometimes, and this is why every April Fools’ Day, the Internet RFC Editor agreed to publish one or more humorous Request For Comments (RFC) documents.

About Lucian Daniliuc

Founder of Monitive.com ◆ Entrepreneur ◆ Software Developer ◆ Certified Scrum Master ◆ Zend Certified Engineer ◆ Passionate about success ◆ Turning into Batman at night ◆ More at http://daniliuc.com