418 I'm a Teapot — réponse HTTP

TL;DR — 418 I'm a teapot est le code de statut humoristique préféré du Web. Il vient de la RFC 2324, une RFC des poissons d’avril consacrée aux cafetières, et n’a jamais reçu de sémantique applicative HTTP ordinaire — mais il est formellement réservé, et non attribué, par la RFC 9110 et le registre de l’IANA. Les recommandations Google datées de 2023 le traitent comme toute autre 4xx non-429 : l’URL n’est pas indexée. Essayez-le sur ce site : /coffee renvoie une vraie 418 — vérifiez l’onglet réseau.

D’où vient la 418 ?

Le 1er avril 1998, l’IETF a publié RFC 2324 : le Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) — un protocole entièrement spécifié et totalement satirique pour contrôler des cafetières sur le Web. Parmi ses contributions : la méthode BREW, l’en-tête Accept-Additions (lait, sirop, whisky) et un code de statut immortel :

418 I’m a teapot — “Any attempt to brew coffee with a teapot should result in the error code ‘418 I’m a teapot’. The resulting entity body MAY be short and stout.” (traduction) : « Toute tentative de préparer du café avec une théière doit produire le code d’erreur “418 I’m a teapot”. Le corps d’entité résultant MAY être court et trapu. »

C’est toute la plaisanterie : vous avez demandé du coffee à une teapot. Elle ne peut pas. C’est une théière.

Seize ans plus tard, la RFC 7168 a repris l’idée pour les appareils qui préparent du thé — une autre RFC informative des poissons d’avril, qui distingue un appareil momentanément à court de café d’un appareil qui est définitivement une théière. Aucune des deux RFC n’attribue de sémantique applicative HTTP ordinaire à 418 ; elles décrivent toutes deux HTCPCP, un protocole satirique, et non le HTTP central.

Pourquoi elle n’est jamais devenue du vrai HTTP

La 418 n’a jamais reçu de sémantique HTTP ordinaire — mais elle n’est pas « non attribuée » pour autant. La RFC 9110, la spécification actuelle des sémantiques HTTP, réserve formellement le code (en rappelant la fréquence de son déploiement comme plaisanterie), et le registre des codes de statut HTTP de l’IANA répertorie 418 comme (Unused), en référence à la RFC 9110 — elle n’est pas disponible pour une réutilisation ordinaire. Preuve à l’appui de cette affirmation RFC 9110 reserves status code 418, citing how often it has been deployed as a joke, and leaves open the possibility of assigning it a different meaning in the future if circumstances require it. Portée : Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Niveau de confiance : élevé · Vérifié : 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) En 2017, le groupe de travail HTTP de l’IETF a proposé de la nettoyer afin de réattribuer le code à quelque chose d’utile. Internet a répondu par une campagne « Save 418 », et la réservation a été maintenue — la RFC 9110 laisse également ouverte la possibilité de la réattribuer plus tard si les circonstances l’exigent. Preuve à l’appui de cette affirmation The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Portée : IANA's current registry entry for status code 418. Niveau de confiance : élevé · Vérifié : 2026-07-16 IANA: HTTP Status Code Registry — 418

Cela n’a pas empêché les implémenteurs d’en faire usage : net/http de Go et le module http de Python exposent tous deux une constante 418 nommée (StatusTeapot, HTTPStatus.IM_A_TEAPOT), et d’autres frameworks et plateformes l’ont adoptée comme easter egg — notamment le google.com/teapot de Google. Preuve à l’appui de cette affirmation Go's net/http and Python's http module both expose a named 418 status constant, showing implementation recognition without requiring servers to emit 418. Portée : Named constants in two mainstream standard libraries; not evidence of a default response. Niveau de confiance : élevé · Vérifié : 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT Une constante nommée ne signifie pas qu’un framework émet 418 par défaut ; cela signifie que le code est reconnu, pas qu’il possède une sémantique HTTP attribuée.

Ce que signifie une 418 pour le SEO

Rien de spécial — et c’est le point important. Google ne décode pas la plaisanterie ; une publication Search Central nommée de février 2023 indique que toutes les réponses 4xx sauf 429 reçoivent le même traitement dans Search : les URL auparavant indexées sont retirées avec le temps et le contenu de la page n’est pas utilisé. Preuve à l’appui de cette affirmation Google's Search Central blog states that all 4xx responses except 429 receive the same treatment for Search: content isn't used and previously indexed URLs are removed over time. Portée : Google Search's dated, named statement on 4xx handling (not 418-specific). Niveau de confiance : élevé · Vérifié : 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting C’est une affirmation générale sur les 4xx, pas une règle spécifique aux théières — la page générique actuelle de Google sur les statuts d’exploration indique explicitement que les statuts exotiques comme 418 ne figurent pas dans son tableau. Preuve à l’appui de cette affirmation Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Portée : Scope note limiting Google's generic HTTP-status guidance to common codes. Niveau de confiance : élevé · Vérifié : 2026-07-16 Google: How HTTP status codes affect Google's crawlers En pratique, une 418 se comporte comme une autre 4xx non-429 du point de vue de l’indexation ; il n’existe aucune règle de classement propre aux théières, aucun calendrier de désindexation ni garantie de récupération au-delà de cette affirmation générale.

C’est ici que la plaisanterie cesse d’être drôle : certaines configurations WAF et de protection anti-robots utilisent 418 comme réponse « requête bloquée », parce qu’elle est distinctive et facile à repérer dans les journaux. Si une telle règle se déclenche par erreur sur Googlebot, vos vraies pages commencent à répondre 418 — et elles sont traitées exactement comme des pages qui n’existent pas.

Si vous voyez des 418 dans les journaux serveur ou les rapports d’exploration sur des URL importantes, le code de statut seul ne vous dit pas quelle couche l’a produit — le code applicatif, un défaut de framework, une règle WAF ou anti-robots, un CDN ou le serveur d’origine peuvent tous le produire, et une réponse peut traverser plusieurs de ces couches avant d’arriver au client. Vérifiez la configuration, les en-têtes de réponse et les journaux du chemin de requête à chaque couche pour trouver la source réelle, puis corrigez-la comme n’importe quelle autre 4xx indésirable sur une URL indexable.

Utilisez cette séquence minimale de diagnostic :

1. Capturez le statut brut et les en-têtes de réponse de l’URL concernée.
2. Comparez les journaux de l’application, de la WAF, du CDN et de l’origine pour le même chemin de requête et le même moment.
3. Corrigez la couche qui émet 418, puis répétez la requête brute et le test d’exploration.

Celle de ce site

Dans l’esprit de la RFC, /coffee sur ce site renvoie une vraie 418, courte et trapue, directement depuis la périphérie. Cette page existe pour donner à cet easter egg une explication canonique — et pour que le cluster http-status-codes couvre le seul code de statut qui fait vraiment sourire.

TL;DR — Traitez un 418 inattendu comme un 4xx ordinaire autre que 429, produit par une couche inhabituelle. Capturez la réponse brute, identifiez l’application, le WAF, le CDN ou l’origine qui l’émet, reproduisez le parcours du robot concerné et surveillez le retour durable au statut prévu.

Interpréter le signal avant toute modification

Le code classe la réponse sans révéler le système qui l’a choisi. Les consignes Google citées placent 418 dans le comportement général des 4xx hors 429 : le contenu n’est pas indexé et une URL déjà indexée peut disparaître avec le temps. Il n’existe aucun rétablissement spécial « théière ».

Commencez par une URL et conservez heure, chemin, statut, en-têtes et corps. Vérifiez si le résultat dépend du user-agent, de l’IP, de l’authentification, du débit ou de la zone géographique.

Isoler la couche émettrice

Progressez de la réponse publique vers l’intérieur :

1. Reproduisez la réponse avec une requête brute et enregistrez en-têtes et corps.
2. Corrélez chemin et heure dans les journaux CDN, WAF, origine, framework et application.
3. Comparez navigateur et robot ; le texte de la page d’erreur ne prouve pas l’émetteur.
4. Modifiez uniquement la règle ou le code démontré ; une constante nommée ne signifie pas qu’un framework émet 418 par défaut.

Vérifier le rétablissement

Retestez l’URL par le chemin qui échouait. Elle doit rendre le statut réellement attendu, généralement 200 pour une page active et indexable. Échantillonnez aussi les URL voisines soumises à la même règle.

Alertez sur tout nouveau 418 d’une URL indexable. /coffee reste le contrôle intentionnel à 418 ; les pages de production ne doivent pas hériter de ce comportement.

Outils pour trouver une 418 inattendue

• Bulk HTTP Status Code Checker : analysez un ensemble d’URL pour y trouver des réponses 418 et distinguer l’easter egg attendu des vraies pages bloquées par une règle WAF ou de protection anti-robots.
• HTTP Header Checker : inspectez les en-têtes CDN et de sécurité pour déterminer quelle couche a généré la réponse.
• Panneau Network des DevTools du navigateur : vérifiez le statut brut de la requête au lieu de vous fier au texte visible de la page d’erreur.
• curl : lancez curl -i https://example.com/path pour capturer le statut, les en-têtes et le corps éventuel de la réponse, sans session de navigateur connectée.
• Événements de sécurité CDN/WAF : si 418 apparaît sur une page qui devrait être indexable, corrélez l’heure de la requête et l’URL avec la règle déclenchée avant de la modifier.

• 418 I'm a teapot vient de la RFC 2324 (HTCPCP), une RFC des poissons d’avril de 1998 ; elle indique qu’on a demandé à une théière de préparer du café. La RFC 7168 a repris le sujet en 2014 pour les appareils qui préparent du thé.
• Elle n’est pas « non attribuée » : la RFC 9110 réserve formellement 418 et le registre de l’IANA la répertorie comme (Unused) — un statut que l’Internet a défendu, pas un statut que personne n’aurait revendiqué. Une tentative de récupération en 2017 a été abandonnée après la campagne « Save 418 ».
• Go et Python exposent tous deux une constante 418 nommée ; d’autres frameworks et plateformes l’implémentent comme easter egg (Google en a une à google.com/teapot) — mais une constante ne signifie pas qu’un framework émet 418 par défaut.
• Effet SEO : une publication Search Central nommée de février 2023 traite toutes les 4xx non-429 de la même manière dans Search — une URL qui répond 418 n’est pas indexée, comme une 404 ; la page générique actuelle sur les statuts d’exploration de Google ne couvre pas les codes exotiques comme 418.
• Risque pratique : une 418 inattendue peut venir de l’application, d’un défaut de framework, d’une règle WAF ou de protection anti-robots, d’un CDN ou de l’origine — vérifiez les en-têtes et les journaux à chaque couche pour trouver la source avant de la corriger comme n’importe quelle autre 4xx.
• Ce site renvoie une vraie 418 sur /coffee.

Journal des modifications