Je chipote sur le protocole cafetière : le HTCPCP

Claude Boellinger 11 décembre 2023 ~ 7 minutes

Tous les premier avril on a droit à la blague de geek Hé tu connais l’erreur 418 Je suis une théière ?. On rigole, on se demande comment des gens aussi sérieux ont pu réfléchir à pondre une norme pareille, mais il faut savoir que derrière ce code d’erreur se cache toute une mécanique monstrueuse dédiée au service de boissons chaudes ! À l’heure où on nous dit tout le temps Bah alors, ton Raspberry Pi ne sait pas faire de café ?, je vais vous expliquer comment y remédier.

C’est quoi une requête HTTP

En accédant à cette page, vous avez envoyé dans un tuyau réseau des chiffres et des lettres pour poser une question à une machine distante : une requête HTTP (HyperText Transfer Protocol).

GET https://www.example.com/ HTTP/2.0
Host: www.example.com
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7

Puis plusieurs autres requêtes pour charger le reste des éléments (images, styles…)

Et le serveur vous a répondu !

HTTP/2.0 200 OK
Server: Apache

Bienvenue sur mon super site !

Il manque bien sûr plein d’éléments dans ces requêtes (type de navigateur, sécurité, cookies…). Pour le reste de cet article, je vais beaucoup simplifier les requêtes et réponses. N’hésitez pas à taper F12 dans votre navigateur pour avoir des exemples.

Le protocole cafetière ou HTCPCP

Le protocole HTCPCP (HyperText Coffee Pot Control Protocol) fonctionne pareil et s’appuie donc sur du texte aussi, mais il faut bien le préciser dans la requête que l’on effectue. Le texte contiendra la « recette » que l’on veut et le serveur (ou la machine) répondra par une réponse avec un code retour.

Premier exemple avec Google

Google propose une page avec une erreur 418. Elle semble propre mais (nous le verrons plus bas) elle n’est pas conforme :

GET https://www.google.fr/teapot HTTP/2.0
Host: www.google.fr

et sa réponse :

HTTP/2.0 418 I’m a teapot

<!doctype html>
<html…

L'exemple de page 418 de Google (oui vous pouvez interagir avec la théière). — L’exemple de page 418 de Google (oui vous pouvez interagir avec la théière).

Je lui fournis un GET et non pas un BREW. POST était autorisé à une certaine époque.
Je reçois un code 418 Je suis une théière alors que d’après le protocole, je devrais recevoir un code 406 Non acceptable, 400 Mauvaise requête voire 500 Problème interne vu que je n’envoie pas de commande de café.
Le corps de la page 418 devrait être « short and stout », or c’est un code de page complexe !

Ce qui aurait été acceptable est que la page sur laquelle on atterrit sur le site de Google soit juste un passe-plat vers le serveur qui commande effectivement la cafetière… Non pardon, la théière. Et à ce compte-là il faudrait un autre code d’erreur pour la page, en l’occurrence une erreur 500 Problème interne vu que le serveur n’a pas réussi à faire l’action demandée (servir du café).

Mise en application

Nous allons donc voir un peu toutes les facettes de la RFC qui décrit ce protocole à travers des cas d’usage classiques. Toutes les requêtes ci-dessous utilisent le HTTP car je ne suis pas sûr d’avoir vu des exemples utilisant HTCPCP. Après tout, ça reste une blague du 1er avril qui ne devrait pas être utilisée sérieusement.

Pour recevoir proprement cette erreur 418, il faut obligatoirement communiquer avec une théière et/ou un serveur respectant le HTCPCP, donc pas juste l’erreur, mais aussi les différentes façons de faire du thé conformément à la RFC.

Pour cela il nous faut :

un socket d’écoute sur une machine physique (mon ordinateur, un Raspberry Pi…) ;
un socket d’appel ou une façon de faire des requêtes personnalisées sur un port (Fiddler par exemple) ;
éplucher la RFC HTCPCP-TEA et l’ancienne version dédiée au café ;
une théière connectée ;
une tasse ;
de l’eau ;
du thé ;
du sucre ;
…

Récupérer l’erreur 418 « proprement »

Dans un premier temps on va simuler un déclenchement de cette erreur 418. D’après la RFC, elle se produit si on cherche à faire du café alors qu’on est une théière. Facile ! On envoie la commande qu’il faut, ou plutôt qu’il ne faut pas :

BREW https://www.example.com/ HTTP/2.0
Host: www.example.com
Accept: message/coffeepot

start

De l’autre côté, il faudra intercepter cette mauvaise commande (comment pourrais-je faire du café moi pauvre théière ?) et créer une réponse avec le code et le texte qui vont bien :

HTTP/2.0 418 I'm a teapot
Server: Teapot server

short and stout

et bien entendu intercepter les mauvaises requêtes, j’ai choisi l’erreur 400 Mauvaise requête.

HTTP/2.0 400 Bad Request
Server: Teapot server

Mauvaise requête, merci de fournir une requête pour infuser du thé.

Voilà c’est tout ! Merci de m’avoir lu et bonnes vacances de Noël !

Infuser du thé

Hélas non ce n’est que le début. Si je choisis de mettre à disposition ce service, je sais exactement ce que vont essayer de faire les gens : ~~déclencher l’erreur 418~~ eh, non ! infuser du thé bien sûr ! Il faut donc implémenter les réponses d’infusion en fonction des choix de l’appelant.

Il faudrait tout gérer, à savoir la demande des recettes et l’ordre d’infusion, mais pour résumer on va se contenter d’une instruction simple d’infusion et de son arrêt :

BREW https://www.example.com/ HTTP/2.0
Host: www.example.com
Accept: message/teapot

start

Et sa réponse :

HTTP/2.0 300 Multiple options
Server: Teapot server
Alternates: {"/darjeeling" {type message/teapot}},
{"/earl-grey" {type message/teapot}},
{"/peppermint" {type message/teapot}}

Merci de fournir une recette de thé.

Comment ça multiples alternatives… Ah oui pardon il faut spécifier quel thé on veut.

BREW https://www.example.com/darjeeling HTTP/2.0
Host: www.example.com
Accept: message/teapot

start

La réponse :

HTTP/2.0 200 OK
Server: Teapot server

Infusion en cours, dites-moi quand il faudra l’arrêter !

Enfin il faut penser à terminer l’infusion.

WHEN https://www.example.com/darjeeling HTTP/2.0
Host: www.example.com
Accept: message/teapot

when

La réponse :

HTTP/2.0 200 OK
Server: Teapot server

Infusion terminée, bonne dégustation !

Oui, à la fin de l’infusion il faut dire « quand » 😉.

Et ce n’est pas fini !

Il manque les additions (sucre…) et aussi le refus d’infuser des thés « contraires aux sensibilités d’un consensus de buveurs de thés » avec un 403 Interdit, et aussi gérer le fait qu’une machine à café pouvant faire du thé peut accepter des BREW de type message/coffeepot (et donc moudre du café).

Le protocole HTPCPCP impose des conditions de sécurité de par le fait que l’on manipule des boissons chaudes et que l’on peut se brûler, ou croiser des collègues matinaux pas encore réveillés sur lesquels on risque de trébucher et de renverser notre breuvage. Si vous avez choisi de faire une implémentation réelle de la théière, pensez quand même à vérifier que quelqu’un ait pris sa tasse à la fin du processus (avec une requête GET bien sûr).

Et enfin, pensez à installer un pare-feu ! Les bouilloires et autres machines à café aujourd’hui n’utilisent pas de feu mais on n’est jamais à l’abri d’un court-circuit.

Pour aller plus loin

Si vous aimez les protocoles exotiques, je vous propose de découvrir le « protocole internet par transporteur aviaires (IPoAC) » qui consiste à transférer des clefs USB par pigeon voyageur ou des avions-cargos remplis de cartes microSD entre deux ordinateurs, si bien sûr vous acceptez un ping qui se chiffre en heures ou en jours.

Bonne dégustation et joyeux Noël !