Кратко

  • draft-ietf-httpbis-pre-denied-01 предлагает код 419, когда сервер отклоняет связанный запрос из-за цели, объявленной в Sec-Purpose; формировать ответ могут источник и шлюз, действующий от его имени.
  • Полученный код подтверждает предъявленную классификацию, но сам не указывает точку решения, внутреннюю причину источника или судьбу следующего запроса. Для атрибуции нужна цепочка транспортных и операционных квитанций.

Клиент получил предложенный 419, а в журнале приложения источника не было запроса. Расследование решило, что журнал потерян: ведь «сервер» ответил. На самом деле решение принял обратный прокси на границе, которому источник делегировал обработку спекулятивного трафика.

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

Редакция 01 документа The Purpose Declined HTTP Status Code опубликована 9 сентября 2026 года как активный Internet-Draft рабочей группы HTTP IETF и истекает 13 марта 2027 года. Документ предназначен для стандартизации, но остаётся изменяемой рабочей версией. На момент фиксации источников код 419 не был назначен в реестре IANA. Это не RFC, не постоянная регистрация, не свидетельство внедрения или совместимости.

Делегирование реально, но не стирает происхождение

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

Такое правило одновременно признаёт власть и ограничивает вывод. Делегированный пограничный узел вправе отказать. Его ответ не является шумом. Но он не доказывает, что код приложения выполнил проверку, что источник был перегружен или что другой путь принял бы то же решение.

Нужна явная запись точки действия: TLS-терминатор, маршрут, Via, Proxy-Status, корреляционный идентификатор, конфигурация делегирования и журналы обеих сторон. RFC 9209 помогает описать обработку посредника, но не превращает его в свидетеля внутреннего состояния источника.

Отсутствие записи у источника подтверждает лишь то, что данный наблюдаемый запрос мог до него не дойти. Оно не называет автоматически виновный промежуточный узел. Атрибуция должна следовать квитанциям, а не удобной топологической догадке.

Код классифицирует отказ, а не создаёт полномочие

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

Получатель может решить, что полная передача не улучшит производительность и принесёт отрицательный эффект. Использование 503 для такого решения смешивает его с временной неспособностью из-за перегрузки или обслуживания, описанной RFC 9110.

Предлагаемый 419 сообщает уже более узкое основание: этот запрос отклонён из-за заявленной цели. Проект прямо говорит, что не вводит новой возможности. Право отказать существовало; номер делает объяснение различимым.

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

Заявленная цель не является человеком

Sec-Purpose описывает контекст, назначенный агентом пользователя. Браузер может начать prefetch по эвристике без клика. Человек может никогда не открыть ссылку.

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

Без этой границы безопасность может превратить оптимизацию браузера в обвинение клиента, а продуктовая аналитика — принятый фоновый запрос в намерение купить. Контекст полезен только пока не занимает место идентичности и результата.

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

Связанный запрос ограничивает время утверждения

Проект устанавливает, что индикация применяется только к связанному запросу. Будущий запрос с той же целью может завершиться успешно или неуспешно.

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

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

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

Кеш не должен расширять решение

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

RFC 9111 определяет общие правила кеширования. Cache-Status из RFC 9211 может показать, был ли ответ переслан, использован повторно или перепроверен. Он не доказывает внутреннюю причину политики, а 419 не доказывает поведение кеша.

Если наблюдаются сто одинаковых ответов, надо различить сто новых решений и сто доставок одного ответа. Возраст, директивы, ключ, путь и журнал решающего узла определяют смысл счётчика.

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

Меньше 503 не означает больше доступности

Отделение цели от 503 способно очистить статистику отказов. Однако перенос событий в 419 не добавляет вычислительных ресурсов и не гарантирует улучшение для пользователя.

Нужно раздельно измерять доступность службы, долю отклонений по цели и результат следующей обычной навигации. Если любой 4xx считается простоем, новая семантика теряется. Если 419 полностью исключить, чрезмерная политика может ухудшать задержку и оставаться невидимой.

Снижение 503 после включения может означать только правильное переименование. Для вывода о здоровье нужны очередь, нагрузка, задержка и фактические исходы. Для вывода о политике нужны цель и точка решения.

Так руководство не путает точный бухгалтерский учёт с появлением нового актива: исправленная запись важна, но сама не меняет производственную реальность.

Тело ответа не является вторым протоколом

Ответы не предназначены для показа пользователю. Им следует иметь нулевое содержимое, а присланное содержимое следует отбросить. Типовая страница может говорить о перегрузке, разрешении или времени повтора без связи с реальной причиной.

Парсинг такого текста создаёт частный нестабильный контракт. Статус несёт только ограниченное утверждение об отказе по заявленной цели. Дополнительным данным нужны собственные формат и происхождение.

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

Источники и ограничения

Зафиксированный пакет включает редакцию 01, статус, историю и ссылки Datatracker, страницу HTTP WG, Fetch Standard, RFC по семантике, кешу и диагностике, BCP 14 и реестр IANA. Он подтверждает текст предложения и состояние документа.

Он не подтверждает внедрение, реальный инцидент, поведение поставщика или будущую публикацию. Начальная сцена — аналитический пример, не сообщение о конкретной сети.

Источники