HTTP 418: a piada de 1998 que o IETF quase apagou em 2017
Em 1º de abril de 1998, o engenheiro Larry Masinter, da Xerox PARC, publicou a RFC 2324 — o Hyper Text Coffee Pot Control Protocol (HTCPCP), um protocolo fictício para controlar cafeteiras pela web. Dentro dela está o código de status HTTP 418, “I’m a teapot” (“Sou um bule de chá”): a resposta que um bule deveria devolver se alguém pedisse para ele coar café. Quase 28 anos depois, o código ainda aparece em bibliotecas HTTP de produção — e quase foi apagado de propósito em 2017.
Uma piada com intenção técnica
A RFC não era só humor gratuito. Masinter disse mais tarde que o objetivo era satirizar a forma como o HTTP vinha sendo estendido de maneira inadequada por propostas da época — o protocolo acumulava métodos e cabeçalhos para tudo, então “controlar uma cafeteira” virou o exagero perfeito para expor o problema. Em 2014, outra RFC de 1º de abril, a 7168 (de Imran Nazar), ampliou a brincadeira para incluir chá, criando o HTCPCP-TEA.
Quando o IETF tentou apagar o 418
Em agosto de 2017, Mark Nottingham, então presidente do grupo de trabalho HTTP do IETF, pediu publicamente que Node.js, Go, Python Requests e ASP.NET removessem o suporte ao 418 de seus códigos-fonte. O argumento era sério: uma piada de RFC não deveria “contaminar” implementações usadas em produção como se fosse um status oficial.
A resposta veio de um desenvolvedor de 15 anos, Shane Brunswick, que criou o site save418.com e lançou o “Movimento Save 418”. A campanha viralizou no Reddit e no Hacker News, e Nottingham recuou da remoção total — em vez de apagar o código, escreveu um rascunho para marcá-lo como reservado no registro oficial.
O que o 418 é oficialmente hoje
O registro da IANA e a RFC 9110, que hoje consolida a semântica do HTTP, listam o 418 como “(Unused)” — sem a definição de teapot, só reservado para não ser reaproveitado por outro status. Mas na prática ele nunca saiu de circulação: em outubro de 2020, o Python 3.9 adicionou http.HTTPStatus.IM_A_TEAPOT citando o próprio movimento de 2017, e o Google mantém até hoje um easter egg em google.com/teapot. Algumas ferramentas de borda também passaram a devolver 418 de propósito como sinal não padronizado de bloqueio — o site do Ministério da Defesa russo, por exemplo, foi flagrado usando o código para visitantes de fora da Rússia como parte de uma defesa contra tráfego indesejado.
Por que isso importa pra quem administra servidor
Se o 418 aparecer num log de aplicação ou numa resposta de API, não é bug do seu código: é herança de uma RFC-piada que sobreviveu a uma tentativa de extinção porque virou símbolo da comunidade. Vale não confundir o código com um status HTTP padronizado e documentado em uso corrente — ele não tem semântica oficial além de “reservado”, então nenhum cliente é obrigado a tratá-lo de forma especial. Ainda assim, se uma ferramenta de proteção de borda estiver devolvendo 418 para bloquear requisições, é bom saber que esse uso é deliberadamente não padronizado antes de gastar tempo “debugando” um erro que, na origem, nunca devia existir.
