Кратко

  • HTTP/2 разрешил использовать постоянное мультиплексированное соединение для запросов с разными компонентами authority в URI, если это подтверждали разрешение имени и сертификат. Таких данных хватало для обоснованной попытки клиента, но они не раскрывали всю внутреннюю маршрутизацию, выбранную по SNI первого рукопожатия.
  • 421 Misdirected Request отвергает пару «источник — соединение». Он не утверждает, что URI переехал, запрос составлен неверно или TLS непременно дал сбой. Клиент может повторить ту же операцию через другое соединение, даже если метод неидемпотентен; обычному прокси создавать 421 запрещено.
  • RFC 8336 добавил кадр ORIGIN, чтобы сервер HTTP/2 заранее объявлял Origin Set соединения, а поддерживающий клиент после 421 удалял из него соответствующий источник. HTTP/3 сохранил код поверх QUIC: долговременная проблема состоит в границе полномочий на общем транспорте, а не в устройстве TCP.

Второе имя подходило к сертификату

У клиента уже открыто зашифрованное соединение с первым сайтом. Ресурс со второго сайта нужен следом. Его имя разрешается в тот же адрес и включено в удостоверение, предъявленное сервером. Новое соединение потребует ещё одного рукопожатия, отдельного состояния транспорта и лишнего ожидания. Существующее уже проверено и способно нести несколько потоков HTTP/2 одновременно.

С внешней стороны повторное использование выглядит правильным. Однако сертификат описывает идентичности, а не весь внутренний план обслуживания. SNI, отправленный при первом установлении, мог выбрать арендатора, TLS-терминатор, правило порта или группу серверов. Один сертификат способен корректно удостоверять два имени, хотя внутренний путь, выбранный для первого, обслуживает только его.

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

У клиента были основания попробовать. У сервера были более точные локальные сведения, чтобы отказать. HTTP понадобилось выражение, которое сохраняло обе истины, — 421.

Host назвал цель, но не назначил отвечающего

Раньше HTTP уже пришлось отделить транспортный адрес от именованного пространства ресурсов. Когда множество сайтов стало делить один IP-адрес, TCP-назначение перестало показывать, какой сайт хотел клиент. HTTP/1.1 обязал запросы передавать Host; в HTTP/2 и HTTP/3 то же намерение обычно несёт :authority.

Так клиент отвечает на вопрос: какой источник мне нужен? У получателя остаётся другой: настроен ли этот источник в данном сервисе и именно в данном контексте соединения?

Действующая RFC 9110 сохраняет оба шага. Хост и порт целевого URI отличают пространство одного источника от других, которыми может управлять сервер. После разбора цели сервер всё равно решает, обрабатывать ли запрос самому, передавать, перенаправлять, отклонять или закрывать соединение, и проверяет требования схемы и контекста.

Host выражает намерение клиента. Он не выдаёт каждому процессу за сокетом полномочия говорить от имени указанного хоста.

HTTP/2 сделал вывод выгодным

Исходная спецификация HTTP/2, RFC 7540, вышла в мае 2015 года. Постоянные соединения и мультиплексирование повысили ценность уже открытого канала. Его можно было повторно использовать для запросов с различными URI authority, если сервер источника выглядел полномочным.

Для TCP без TLS новый хост, среди прочего, должен был разрешаться в тот же IP-адрес. Для HTTPS сертификат дополнительно должен был пройти проверки, которые клиент выполнил бы при новом соединении с этим хостом. Несколько subjectAltName или подходящее масочное имя могли покрывать несколько источников.

Это было не безусловное объединение, а осторожное решение по проверяемым снаружи данным. Но клиент мог не видеть, какой выбор сделан за границей TLS.

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

DNS не обязательно был неверен, сертификат — подделан, а сообщение — испорчено. Клиенту не хватало одного факта, известного получателю: этот контекст не отвечает за этот источник.

421 отклонил ребро, а не его вершины

RFC 7540 ввела 421 Misdirected Request. Сегодня его определение находится в RFC 9110 среди общей семантики HTTP.

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

Код не объявляет ресурс исчезнувшим и не сообщает о переезде источника. Он не предлагает другой URI. Он не обязательно делает соединение непригодным для прочих запросов. Отвергается конкретное отношение: этот источник не будет представлен через это соединение.

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

Без надёжного происхождения отрицательное свидетельство только добавило бы неопределённости.

Достижимость, удостоверение и принятие контекста

Три утверждения легко принять за одно. Соединение достигает конечного узла. Узел предъявляет сертификат, приемлемый для целевого источника. Система настроена и согласна дать полномочный ответ этого источника в конкретном соединении.

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

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

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

Повтор менял контекст доставки

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

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

Даже здесь клиент не обязан продолжать. Тело может быть невоспроизводимо, учётные данные — привязаны к каналу, локальная политика — запрещать повтор, а необратимая операция — требовать подтверждения. Протокол даёт возможность, а не принимает риск за приложение.

Для восстановления должно измениться условие. Бесконечно слать по уже отклонённому общему соединению бессмысленно. URI, метод и намерение сохраняются; новое соединение может отправить SNI целевого источника и выбрать другой фронтенд или backend, даже если придёт к тому же адресу и увидит тот же сертификат.

Смысл запроса не меняется; меняется его носитель.

Это не скрытый редирект

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

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

421 не равен 400 Bad Request: сообщение может быть синтаксически верным. Это не 403 Forbidden, потому что в центре не право пользователя на ресурс. И не ошибка TLS: успешная проверка сертификата могла как раз побудить клиента повторно использовать соединение.

Узкий код не позволяет словарю одного слоя присвоить смысл другого.

ORIGIN сообщил часть знания заранее

Реактивное исправление стоит времени: запрос уже отправлен, прежде чем приходит отказ. RFC 8336, опубликованная в марте 2018 года, определила кадр HTTP/2 ORIGIN, чтобы сервер мог объявить источники, для которых пригодно соединение.

Набор называется Origin Set. После инициализации поддерживающий клиент не должен считать соединение полномочным для отсутствующего в нём источника. Записи задают конкретные origins и не допускают масок. Поэтому широкий wildcard-сертификат не превращается автоматически в столь же широкое эксплуатационное объявление.

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

После 421 клиент, реализующий RFC 8336, удаляет соответствующий источник из Origin Set этого соединения. Отказ становится обновлением знания для следующего выбора, а не забытым экраном ошибки.

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

Alt-Svc указывал путь, но не самоназначал полномочия

Alt-Svc позволяет источнику объявить другой хост, порт или протокол как эквивалентный сервис. Клиент может выбрать его после 421. Но объявление не отменяет проверок authority и само по себе не меняет Origin Set.

DNS даёт сведения о достижимости, сертификат — об идентичности, Alt-Svc — об альтернативе, ORIGIN — о намерении использовать соединение. Получатель знает фактически выбранный контекст. Каждое свидетельство отвечает на отдельный вопрос.

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

Ограниченные сигналы способны сотрудничать именно потому, что ни один не становится общим правителем.

HTTP/3 сменил транспорт, но сохранил границу

Действующая спецификация HTTP/2 RFC 9113 заменила RFC 7540 и сохранила как повторное использование между источниками, так и 421. RFC 9114 перенесла HTTP на QUIC и оставила тот же код.

Соединения HTTP/3 также постоянны и могут нести запросы с разными URI authority. Перед использованием существующего соединения для нового источника клиент обязан проверить сертификат для этого источника. Неприемлемый сертификат запрещает повторное использование. Но и при приемлемом сертификате сервер может вернуть 421, если не хочет обслуживать конкретный источник через данное HTTP/3-соединение.

История отделяет принцип от первой реализации. Код родился в HTTP/2, перешёл в общую семантику и сохранился в HTTP/3. Проблема не была свойством TCP или одного формата кадра.

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

Наблюдать нужно отклонённую связь

Общее число 421 не объясняет причину. Каждое событие надо связывать со схемой, хостом и портом цели; методом; версией HTTP; идентификаторами соединения и потока; удалённым endpoint; SNI и ALPN; именами сертификата; DNS-результатом, обосновавшим повторное использование; происхождением Alt-Svc; Origin Set; выбранными фронтендом и backend; ролью эмитента; идентификатором и результатом следующего соединения.

Если общее соединение получает 421, а новое для источника успешно, главным объяснением становится выбор контекста. Если оба получают 421, источник, возможно, вообще не настроен. Если сбой ограничен регионом, стоит сравнить моменты распространения сертификатов, объявлений и backend-конфигурации.

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

Общий транспорт не означал общее управление

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

Клиент принимает предварительное решение по видимым сведениям. Получатель решает по SNI, арендатору, порту и backend, может ли говорить за источник. При расхождении URI и операция остаются прежними, а контекст меняется.

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

Действующий реестр кодов состояния HTTP IANA содержит 421 под именем Misdirected Request и ссылается на RFC 9110. Регистрация закрепляет совместимое имя и нормативную ссылку; она не доказывает частоту применения, одинаковое поведение всех клиентов или правильность настройки конкретной системы.

Соединение было настоящим. Второй источник тоже. Не существовало только полномочия первого представлять второй. Код 421 зафиксировал именно это отсутствие.