Кратко

  • Активный черновик рабочей группы HTTP предлагает 419 Purpose Declined, когда сервер отклоняет запрос из-за заявленного Sec-Purpose. Это квитанция для одного запроса, не постоянный запрет, не диагноз здоровья и не новое право отказа. На 29 сентября 2026 года IANA всё ещё указывала 419–420 как не назначенные.
  • Назначение, уполномоченная точка решения, запрет кэширования, поведение старых клиентов, популяция SLO и последующий реальный спрос должны оставаться связанными. Иначе 419 сворачивается в «прочие 4xx», а прежняя ошибка наблюдения сохраняется.

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

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

Но 503 Service Unavailable сообщает другую реальность. В RFC 9110 класс 5xx означает, что сервер не выполнил внешне корректный запрос. Дежурный, который ищет перегрузку при росте 503, рассуждает верно. Ошибка возникла раньше, когда добровольный отказ включили в тот же счётчик.

draft-ietf-httpbis-pre-denied-01 от 9 сентября 2026 года предлагает 419 Purpose Declined: сервер отклонил данный запрос по его объявленной цели. Это активный Internet-Draft группы HTTP, ориентированный на Standards Track, но не RFC. При фиксации источников 419–420 оставались unassigned в IANA.

Черновик не создаёт новую возможность отказа. Он делает видимой границу: сервис не мог выполнить работу или локально не допустил необязательную работу?

Заявленная цель — контекст, а не доказанный спрос

Fetch определяет Sec-Purpose для целей, отличных от немедленного использования человеком. Единственный определённый token — prefetch: ресурс ожидается нужным в ближайшее время. При таком initiator алгоритм устанавливает Sec-Purpose: prefetch.

Сервер может изменить срок кэша, запретить prefetch или считать его отдельно от посещения. Заголовок не доказывает будущий переход, точность прогноза, личность или пользу. Он сообщает контекст.

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

Неверная категория расходует реальные ресурсы

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

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

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

Отказ должен закончиться вместе с запросом

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

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

Ответ не предназначен для показа, должен иметь нулевое содержимое, а отправленное содержимое следует отбросить. Объяснение хранится в контексте, версии policy и trace, а не в новой странице ошибки.

Тест повторяет prefetch при изменённых условиях, затем выполняет прямой запрос. Он проверяет отсутствие replay, достижение правильной точки решения и отсутствие пустого ответа в UI.

У отправителя 419 должно быть полномочие

419 могут генерировать origin и действующие от его имени шлюзы — CDN или reverse proxy. Другие proxy не должны. Иначе посторонний посредник сможет удалить запрос и ложно приписать решение сервису.

Квитанция должна содержать точку генерации, делегирование, policy version, правило и входы. Sec-Purpose не аутентифицирует отправителя. Способность CDN доставлять объект не равна общему мандату на изменение допуска.

Черновик отмечает возможную утечку внутреннего состояния. Если 419 меняется с нагрузкой или порогом, policy можно исследовать. Нужно ограничивать детализацию и probing, а не возвращать семантическую путаницу 503.

Старый клиент сохранит класс, но может потерять причину

RFC 9110 требует трактовать неизвестный 4xx как общий эквивалент 400. Клиент не примет 419 за успех, однако SDK может назвать его bad request, журнал — other_4xx, retry-библиотека — ошибкой входа, а панель снова покрасит красным.

Running-Code Primacy требует испытать клиент, edge, origin, cache, tracing, метрики, alert, SLO и отчёт. Будущая регистрация сама не перепишет эти компоненты.

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

Связать код с последующим исходом

Полная запись включает request ID, method, target, initiator, Sec-Purpose, client build и cache state; затем decision point, делегирование, версию, правило и время; потом status, cache-control, длину и позицию trace. В конце присоединяется реальный спрос, успех, latency, bytes, работа origin и видимый результат.

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

Доступность немедленного спроса и admission rate prefetch требуют разных SLO. Их полезно сопоставлять со стоимостью и опытом, но не смешивать знаменатели.

Первичные источники подтверждают предложение, процесс, Fetch-семантику, HTTP-правила и отсутствие назначения IANA. Они не подтверждают браузер, CDN, внедрение, экономию, adoption или совместимость. Для этого нужны реализации и измерения.

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

Источники