Кратко

  • В январе 1997 года RFC 2068 включил 402 Payment Required в HTTP/1.1 и оставил ему одну инструкцию: «зарезервирован для будущего использования».
  • RFC 2616, RFC 7231 и RFC 9110 сохранили эту оговорку. В HTTP для 402 так и не появились общая цена, запрос оплаты или правила расчёта.

Вывеска появилась раньше кассы

RFC 1945 объяснял коды состояния как машинно-читаемые результаты и перечислял значения, признанные в HTTP/1.0. В списке клиентских ошибок после 401 Unauthorized сразу шёл 403 Forbidden; 402 там не было. Спецификация разрешала коды расширения, поэтому незарегистрированный номер мог использоваться как расширение. Собственного определения в опубликованном перечне он не получил. RFC 1945 §§6.1.1–6.1.2

В январе 1997 года RFC 2068 включил 402 в грамматику кодов HTTP/1.1 и отвёл ему раздел 10.4.3. Вся норма уместилась в одно предложение: «This code is reserved for future use.» Название обозначило платный барьер, но стандарт не объяснил, как его пройти. RFC 2068 §§6.1.2, 10.4.3

Код сообщает вид ответа, но не содержимое сделки. В определении 402 нет суммы, валюты, получателя, формы платёжного подтверждения, подтверждения операции, расчёта или процедуры спора. Сервер может изложить собственные условия в теле ответа; HTTP не делает их общими для разных клиентов и сервисов.

Для 401 есть запрос учётных данных. Для 402 — только зал ожидания.

Соседний 401 показывает, как стандарт задаёт общий порядок действий. RFC 9110 требует включать в ответ 401 поле WWW-Authenticate хотя бы с одним подходящим вызовом аутентификации. Клиент может прочитать способ и понять, какие данные передать. Раздел 15.5.3 не даёт 402 подобной инструкции: там повторена только оговорка о будущем. RFC 9110 §§15.5.2–15.5.3

Недостающую работу выполняет приложение. Сервис, который закрывает ресурс оплатой, должен определить сумму, доказательство платежа, получателя и порядок действий при отказе или незавершённом расчёте. HTTP ставит табличку. Кассу, квитанцию и обработку ошибки строит сам сервис.

Будущее продлевали от редакции к редакции

RFC 2616 повторил ту же фразу в июне 1999 года, в разделе 10.4.3. RFC 7231 сделал это в 2014-м, RFC 9110 — снова в 2022-м. Номер раздела менялся; резерв оставался. Каждая новая редакция обновляла семантику HTTP и переносила пустое место для оплаты дальше. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

RFC не называют платёжную систему, которую могли иметь в виду авторы. Современная документу проектная запись с конкретным названием изменила бы историческое объяснение. Опубликованные стандарты сообщают название и сохраняют резерв, но не рассказывают, для чего его готовили.

В проверенной для этой статьи записи реестра IANA, обновлённой 15 сентября 2025 года, код 402 по-прежнему обозначен как «Payment Required» со ссылкой на RFC 9110, раздел 15.5.3. Реестр кодов состояния HTTP IANA

Интеграционная стоимость возвращается разработчикам

Здесь видна экономика интерфейса для разработчиков. Общий протокол мог бы избавить команды от повторного описания одного и того же обмена в частных инструкциях. HTTP 402 этой работы не выполняет. Клиент покупателя и сервер должны на уровне приложения договориться о цене, подтверждении, учётных данных, повторных попытках и завершении платежа. Разработчики несут расходы на интеграцию и поддержку; сервисы сохраняют контроль над собственными условиями.

Поэтому 402 — название состояния, а не платёжный интерфейс. Он говорит клиенту, что доступ связан с оплатой, но не даёт общего способа её выполнить. Касса в HTTP остаётся локальным правилом под стандартным номером.

Источники