Коды ответа HTTP — вещь скучная и предсказуемая. Двухсотый: всё хорошо. Четыреста четвёртый: такой страницы нет. Пятисотый: сервер упал, разбирайтесь сами. Каждый номер занимает своё место в спецификации, у каждого есть смысл, и обсуждать тут нечего.
Кроме одного. Откройте в браузере google.com/teapot — сервер Google ответит вам кодом 418 I'm a teapot. «Я чайник». Это не ошибка конфигурации и не шалость одного инженера: код существует официально, лежит в реестре IANA и упомянут в действующем стандарте HTTP.
Откуда взялся чайник
Первого апреля 1998 года вышел RFC 2324 — документ, описывающий Hyper Text Coffee Pot Control Protocol, протокол управления кофеварками поверх HTTP. Полностью выдуманный, но написанный с той же серьёзностью, что и настоящие стандарты.
В нём есть метод BREW вместо POST. Есть метод WHEN — чтобы сказать «хватит», когда молока налили достаточно. Есть заголовок Accept-Additions, где перечислены допустимые добавки: Cream, Half-and-half, Whole-milk для молока, Vanilla, Almond, Raspberry для сиропов и отдельной строкой Whisky, Rum, Kahlua, Aquavit.
И раздел 2.3.2 с тем самым кодом:
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.
Если попросить заварить кофе устройство, которое является чайником, оно обязано ответить отказом с кодом 418. А тело ответа, добавляет спецификация, «может быть маленьким и толстеньким» — это строчка из детской песенки «I'm a Little Teapot». Такой уровень проработки шутки.
Шутка оказалась долгоиграющей. Через шестнадцать лет, тоже первого апреля, вышло продолжение — RFC 7168 «The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances», расширяющее протокол на заварку чая.
Почему его нельзя было просто удалить
Дальше произошло то, чего авторы шутки не планировали. Разработчики начали ставить 418 в реальный код: как заглушку, как ответ ботам, как пасхалку. Библиотеки HTTP добавили его в списки констант. Гуглов /teapot — из этой же серии.
Когда в 2022 году вышел RFC 9110 — действующая на сегодня спецификация HTTP — комитету пришлось с этим что-то делать. Раздел 15.5.19 объясняет ситуацию сухо и почти обиженно:
RFC 2324 был первоапрельским документом, высмеивающим разные способы злоупотребления HTTP; одним из таких злоупотреблений было определение прикладного кода 418, который развёрнут в качестве шутки достаточно часто, чтобы код стал непригоден для любого будущего использования.
Поэтому код 418 зарезервирован в реестре кодов состояния HTTP IANA.
Проверить можно самому: в реестре IANA напротив 418 стоит (Unused) — единственная запись такого рода среди четырёхсотых. Соседние 419 и 420 честно помечены как Unassigned, свободные. А 418 — занят. Занят шуткой.
Оговорка в стандарте всё же оставлена: если номера в диапазоне 4xx однажды кончатся, код можно будет переназначить. Пока не кончились.
Что с этим делать инженеру
Ничего — и в этом весь смысл. Но история полезна как напоминание о том, как устроены стандарты, на которых держится ваша инфраструктура.
Спецификация — не скрижаль. Это договор между теми, кто пишет код, и он подстраивается под то, что люди уже делают, а не наоборот. Один шуточный документ, написанный за вечер, оказался сильнее комитета: не потому, что был убедителен, а потому, что его реализовали в тысячах мест и обратно уже не собрать.
Ровно так же ведут себя и вещи посерьёзнее. X-Forwarded-For появился как самоделка одного прокси и стал стандартом де-факто задолго до того, как его формализовали. Referer попал в спецификацию с опечаткой в слове и живёт с ней тридцать лет. Реальность приживается первой, документ догоняет.
А если однажды на проде вы увидите в логах 418 — проверьте, кто именно его вернул. Скорее всего, это ваш собственный балансировщик, которому кто-то поставил заглушку и забыл.
Впервые опубликовано в моём блоге на SecurityLab 19 февраля 2025 года. Здесь — расширенная версия: добавлены формулировка действующего стандарта RFC 9110 и проверка по реестру IANA.