418: sono una teiera

TL;DR — 418 I'm a teapot è il codice di stato scherzoso più amato del web. Deriva da RFC 2324, un RFC del Pesce d’aprile sui bricchi del caffè, e non ha mai ricevuto semantica ordinaria per le applicazioni HTTP; tuttavia è riservato formalmente, non “unassigned”, secondo RFC 9110 e il registro IANA. Le indicazioni datate di Google del 2023 lo trattano come qualsiasi altro 4xx diverso da 429: l’URL non viene indicizzato. Provalo su questo sito: /coffee risponde con un vero 418 — controlla la scheda Network.

Da dove proviene il 418

Il 1° aprile 1998, l’IETF pubblicò RFC 2324: il protocollo di controllo delle caffettiere Hyper Text (HTCPCP/1.0) — un protocollo completamente specificato e interamente satirico per controllare le caffettiere sul web. Tra i suoi contributi: il metodo BREW, l’header Accept-Additions (latte, sciroppo, whisky) e un codice di stato immortale:

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.” (traduzione) «Ogni tentativo di preparare il caffè con una teiera dovrebbe restituire il codice di errore «418 I’m a teapot». Il corpo risultante PUÒ essere corto e robusto.»

Glossa italiana: Ogni tentativo di preparare il caffè con una teiera dovrebbe restituire il codice di errore «418 I’m a teapot». Il corpo dell’entità risultante PUÒ essere corto e robusto.

Questa è tutta la battuta: hai chiesto a una teiera del caffè. Non può farlo. È una teiera.

Sedici anni dopo, RFC 7168 riprese l’idea per gli apparecchi che preparano il tè — un altro RFC Informational del Pesce d’aprile, questa volta distinguendo un apparecchio che è temporaneamente senza caffè da uno che è una teiera, in modo permanente. Nessuno dei due RFC assegna al 418 una semantica ordinaria per le applicazioni HTTP; entrambi descrivono HTCPCP, un protocollo satirico, non il nucleo di HTTP.

Perché non è mai diventato HTTP reale

Il 418 non ha mai ricevuto una semantica ordinaria per HTTP, ma non è nemmeno “unassigned”. RFC 9110, la specifica attuale della semantica HTTP, riserva formalmente il codice (citando quanto spesso è stato usato come scherzo), e il Registro IANA dei codici di stato HTTP elenca 418 come (Unused), facendo riferimento a RFC 9110: non è disponibile per il riuso ordinario. Evidence for this claim 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. Scope: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Confidence: high · Verified: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) Nel 2017 il gruppo di lavoro HTTP dell’IETF propose di eliminarlo così da poter riassegnare il codice a qualcosa di utile. Internet rispose con la campagna “Save 418”, e la riserva rimase: RFC 9110 lascia inoltre aperta la possibilità di riassegnarlo in seguito se le circostanze lo richiedessero. Evidence for this claim The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Scope: IANA's current registry entry for status code 418. Confidence: high · Verified: 2026-07-16 IANA: HTTP Status Code Registry — 418

Quella riserva non fermò gli implementatori: net/http di Go e il modulo http di Python espongono entrambi una costante 418 denominata (StatusTeapot, HTTPStatus.IM_A_TEAPOT), e altri framework e piattaforme hanno seguito l’esempio come easter egg — tra questi lo stesso google.com/teapot di Google. Evidence for this claim 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. Scope: Named constants in two mainstream standard libraries; not evidence of a default response. Confidence: high · Verified: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT Una costante denominata non significa che un framework emetta 418 per impostazione predefinita; significa che il codice è riconosciuto, non che abbia semantica HTTP assegnata.

Cosa significa un 418 per la SEO

Nulla di speciale — ed è proprio questo il punto da conoscere. Google non interpreta la battuta; un post di Search Central del febbraio 2023, con titolo esplicito dice che tutte le risposte 4xx tranne 429 ricevono lo stesso trattamento nella Ricerca: gli URL indicizzati in precedenza vengono rimossi nel tempo e il contenuto della pagina non viene utilizzato. Evidence for this claim 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. Scope: Google Search's dated, named statement on 4xx handling (not 418-specific). Confidence: high · Verified: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting È un’affermazione generale sui 4xx, non una regola specifica per le teiere: l’attuale pagina generica di Google sullo stato dei crawler dice esplicitamente che gli stati esotici come 418 non sono inclusi nella sua tabella. Evidence for this claim Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Scope: Scope note limiting Google's generic HTTP-status guidance to common codes. Confidence: high · Verified: 2026-07-16 Google: How HTTP status codes affect Google's crawlers Nella pratica, per l’indicizzazione un 418 si comporta come un altro 4xx diverso da 429; non esistono una regola di ranking specifica per le teiere, una tempistica di deindicizzazione o una garanzia di recupero oltre a quell’affermazione generale.

Qui smette di essere divertente: alcune configurazioni WAF e di protezione dai bot usano 418 come risposta “blocked request” (“richiesta bloccata”), con l’idea che sia distintiva e facile da individuare nei log. Se una regola del genere scatta erroneamente su Googlebot, le tue pagine reali iniziano a rispondere 418 — e vengono trattate esattamente come pagine che non esistono.

Se vedi 418 nei log del server o nei report di scansione su URL importanti, il solo codice di stato non ti dice quale livello lo ha generato — possono produrlo il codice dell’applicazione, un valore predefinito del framework, una regola WAF o di protezione dai bot, una CDN o il server di origine, e una risposta può attraversarne diversi prima di arrivare al client. Controlla configurazione, header della risposta e log del percorso della richiesta a ogni livello per trovare la fonte effettiva, quindi correggila come qualsiasi altro 4xx indesiderato su un URL indicizzabile.

Usa questa sequenza diagnostica minima:

1. Acquisisci lo stato grezzo e gli header di risposta dell’URL interessato.
2. Confronta i log dell’applicazione, del WAF, della CDN e dell’origine per lo stesso percorso di richiesta e orario.
3. Correggi il livello che emette 418, quindi ripeti la richiesta grezza e il test del crawler.

Quello su questo sito

Nello spirito dell’RFC, /coffee su questo sito restituisce un 418 reale, corto e robusto, direttamente dall’edge. Questa pagina esiste perché quell’easter egg abbia una spiegazione canonica — e perché il cluster http-status-codes copra l’unico codice di stato che fa davvero sorridere.

Strumenti per trovare un 418 inatteso

• Controllo massivo dei codici di stato HTTP: scansiona un insieme di URL alla ricerca di risposte 418 e distingue l’easter egg intenzionale dalle pagine reali bloccate da una regola WAF o di protezione dai bot.
• Controllo degli header HTTP: esamina gli header CDN e di sicurezza alla ricerca di indizi sul livello che ha generato la risposta.
• Pannello Network degli Strumenti per sviluppatori del browser: verifica lo stato grezzo della richiesta invece di affidarti al testo visibile della pagina di errore.
• curl: esegui curl -i https://example.com/path per acquisire stato, header ed eventuale corpo della risposta senza una sessione del browser autenticata.
• Eventi di sicurezza CDN/WAF: se 418 compare su una pagina che dovrebbe essere indicizzata, correla l’ora della richiesta e l’URL con la regola che è scattata prima di modificarla.

• 418 I'm a teapot deriva da RFC 2324 (HTCPCP), un RFC del Pesce d’aprile del 1998; segnala che a una teiera è stato chiesto di preparare il caffè. RFC 7168 lo riprese nel 2014 per gli apparecchi che preparano il tè.
• Non è “unassigned”: RFC 9110 riserva formalmente 418, e il registro IANA lo elenca come (Unused): uno stato che Internet ha difeso per conservarlo, non uno che nessuno ha rivendicato. Un tentativo del 2017 di recuperare il codice fu abbandonato dopo la campagna “Save 418”.
• Go e Python espongono entrambi una costante 418 denominata; altri framework e piattaforme la implementano come easter egg (Google ne ha una propria in google.com/teapot) — ma una costante non significa che un framework emetta 418 per impostazione predefinita.
• Impatto SEO: un post di Search Central di febbraio 2023 tratta ogni 4xx diverso da 429 allo stesso modo nella Ricerca — un URL che risponde 418 non viene indicizzato, come un 404; l’attuale pagina generica di Google sullo stato dei crawler non copre affatto codici esotici come 418.
• Rischio pratico: un 418 inatteso potrebbe provenire dall’applicazione, da un valore predefinito del framework, da una regola WAF o di protezione dai bot, da una CDN o dall’origine — controlla header e log a ogni livello per trovare la fonte prima di correggerla come qualsiasi altro 4xx.
• Questo sito restituisce un vero 418 su /coffee.

Cronologia modifiche