Кратко

  • 9 сентября 2026 года HTTPbis опубликовала редакцию 01 draft-ietf-httpbis-pre-denied. Это активный документ рабочей группы, а не RFC и не подтверждение назначения 419 регистратурой IANA.
  • Название изменено с “Preliminary Request Denied” на Purpose Declined, предложен номер 419, а смысл распространён на отказ из-за значения Sec-Purpose. Сейчас Fetch определяет только токен prefetch.
  • Ответ может создать источник или шлюз, действующий от его имени. Независимому прокси делать этого не следует. Различие касается права представлять политику сервиса, а не технической возможности сформировать HTTP-ответ.
  • Статус не называет применённое правило. Я предлагаю минимальную запись, связывающую цель, решающую сторону, делегирование, версию политики, время, кеширование и результат. Это редакционное предложение Daniel Kade, не требование draft.

Главная перемена скрыта не в числе 419

В 08:56 UTC 9 сентября Datatracker сделал доступной редакцию 01 The Purpose Declined HTTP Status Code. Предыдущий текст оставлял общий заполнитель 4xx и говорил об отклонении предварительного запроса, прежде всего prefetch или preload. Новая версия выбирает 419 и охватывает запрос, которому отказали на основании заявленной цели.

Положение документа в процессе нельзя ни обесценивать, ни преувеличивать. Это Active-документ рабочей группы HTTPbis в IETF stream, с предполагаемым статусом Proposed Standard и Tommy Pauly в роли document shepherd. Однако состояние IESG — лишь I-D Exists; ответственного Area Director, обработки IESG и telechat нет. В действующем реестре IANA диапазон 419-420 остаётся Unassigned. Номер пока принадлежит рабочему проекту.

Редакция отдельно определяет участников. Сервер-источник может вернуть новый статус. CDN или reverse proxy тоже может, если выступает шлюзом от имени источника. Независимому прокси генерировать его не следует.

Это не запрет, обеспеченный физикой. Любой посредник, способный прервать обмен, технически может создать 4xx. Текст ограничивает право на смысл: собственное решение транзита нельзя выдавать за политику приложения. Близость к источнику в сетевой схеме не равна делегированию.

Sec-Purpose фиксирует заявление, а не истинное намерение

В Fetch Standard у Sec-Purpose узкая роль. Структурированный заголовок сообщает, что запрос служит цели, отличной от немедленного использования. На момент публикации определено единственное значение — prefetch. Сервер может учесть его в сроке хранения, запретить предварительную загрузку или иначе посчитать посещение.

Более широкое имя “Purpose Declined” оставляет пространство для будущих токенов, но не создаёт их. Не создаёт оно и новой власти сервера: отказать можно было и раньше. Как отмечает сам документ, предлагаемая реакция лишь делает существующее поведение понятнее клиентам и операторам.

Понятность не следует принимать за доказательство. Sec-Purpose: prefetch показывает, как клиент охарактеризовал запрос. Он не доказывает желание пользователя, согласие на фоновую загрузку, происхождение вызова из конкретного модуля или точность декларации. В обратную сторону 419 не раскрывает, сработало ли абсолютное правило, нагрузка, стоимость, география, сигнал злоупотребления, класс контента или исключение.

Протокол подтверждает две ограниченные вещи: клиент заявил цель, а уполномоченный серверный участник отказал на этом основании. Этого недостаточно для общего вердикта о добросовестности трафика или намерениях человека.

Мандат шлюза должен оставаться проверяемым

На периферии владелец политики и исполнитель часто разделены. CDN завершает соединение до приложения и запускает правила конкретного tenant. Reverse proxy защищает несколько сервисов. Такое размещение экономит ресурсы, но при ошибке усложняет вопрос «кто решил».

Из строки статуса не видно, решила ли сама программа, исполнил ли шлюз явно порученное правило или вмешался административно независимый посредник. Не указаны делегировавший источник, версия политики и проверенные исключения.

Выводить все эти сведения в публичный ответ опасно. Раздел Security в draft предупреждает, что отказ по цели способен раскрыть внутреннее состояние сервера. Поэтому нужен не многословный wire-протокол, а контролируемое операционное свидетельство: точный токен Sec-Purpose; компонент и его роль; источник или tenant, от чьего имени он действует; устойчивый идентификатор и версия политики; время; результат; отправленные правила кеширования; безопасный класс причины, если его можно открыть.

Это не предложение собирать профиль пользователя или хранить содержание просмотра. Запись ограничена тем, что позволяет воспроизвести спорное решение и проверить пределы делегирования. Само место шлюза в сети полномочий не подтверждает.

Запрет на кеш ограничивает срок действия власти

Редакция 01 требует нулевой длины содержимого и рекомендует отбросить тело, если оно всё же пришло. Кроме того, 419 не считается эвристически кешируемым и не должен сохраняться. Так единичное контекстное решение не превращается в длительную блокировку без повторной оценки.

RFC 9110 оставляет совместимый путь: клиент, не знающий 419, должен трактовать его как x00 своего класса, то есть как общий 4xx. RFC 9111 задаёт обычную модель хранения. Более строгая норма draft нужна, чтобы отказ при определённой нагрузке или версии политики не воспроизводился после изменения условий.

На общем шлюзе сохранённый ответ может пересечь границу tenant, пережить исправление или попасть на запрос с иным контекстом. Он выглядит как свежее решение источника, хотя источник новый случай не рассматривал. Поэтому способ кеширования следует хранить вместе с участником, мандатом и версией.

Устойчивая схема разделяет три слоя: минимальный общий смысл в HTTP, внутреннее свидетельство ответственности и локальное решение о том, какую причину безопасно сообщить клиенту.

Источники