LockerGnomeTech news and nostalgia for today's technology professionals
Subscribe

Search

Retro

HTTP’s teapot joke also specified when a coffee pot should stop pouring milk

Larry Masinter’s 1998 informational memo applies painstaking protocol design to breakfast, with optional whiskey.

Chris holds a coffee mug out to a teapot that refuses to brew coffee
Illustration: LockerGnome

A networked coffee pot needs to know when to stop pouring milk. Somebody actually wrote that into a protocol.

Larry Masinter’s RFC 2324 is the source of the Hyper Text Coffee Pot Control Protocol, or HTCPCP. The date is April 1, 1998. Its opening status note explicitly says the memo does not specify an internet standard. Treating it as a joke is therefore compatible with reading the documentation. A rare win for both departments.

The famous line appears under response code 418. When somebody asks a teapot to brew coffee, it should respond with that error. The body, Masinter writes, “MAY be short and stout.” There is your nursery rhyme, expressed in the language of implementation requirements.

The rest of the document commits to the setup with alarming thoroughness. A coffee pot accepts BREW or POST commands with a coffee-specific content type. POST is deprecated for this purpose. The memo gives an appropriately ridiculous justification involving the name of a coffee brand, and adds BREW so the protocol can get on with breakfast.

The milk problem gets its own method: WHEN. That lets the recipient signal that enough milk has arrived. Anyone who has watched a splash of milk become an entire dairy intervention already understands the requirement. The protocol merely makes the intervention remotely addressable.

Additions use a header that distinguishes milk, syrup, sweetener, spice and alcohol. Cream and half-and-half get places in the grammar. So do vanilla, raspberry, whiskey, rum and Kahlua. There is no decaffeinated option. An impressive amount of interoperability work went into making sure the wrong beverage would not happen by accident.

A retry header goes further into the practical hazards. Repeating a network request can be harmless for information retrieval and messy when it operates a physical machine. Here, the safe condition can depend on whether the user is awake. The joke works because the underlying engineering issue is familiar: a successful retry can produce a second physical action.

The coffee URI scheme also accommodates the word for coffee in 29 languages, with UTF-8 characters represented through URL encoding where needed. It is an oddly elaborate reminder that software’s friendly-looking names still have to travel through rules. Even a prank cannot escape character encoding. Grounds for complaint, certainly.

A modern connected appliance could benefit from the same questions this memo satirizes. What happens after a retry? Can the device fulfill the requested action? How does it say that it cannot? The RFC makes those problems visible by choosing an object whose failure modes fit on the kitchen counter.

The teapot response gets most of the souvenirs, but the milk command is the wonderfully human part. A computer needs an explicit stopping condition for an action that a person usually ends with one word. Whether an actual pot ever needed all these headers is left well outside the memo’s requirements.

Enough milk. Say WHEN.

More Retro

Every Retro story →