Кратко

  • Проект REGEXT об расширениях RDAP запрещает серверу без разбора копировать параметры запроса в URL перенаправления. Передача возможна, когда исходный сервер знает, что адресат способен обработать параметр и является подходящим получателем его содержимого.
  • Расширение, предназначенное для поиска полномочного сервера через границы разных организаций, не может рассчитывать на сохранение параметра при каждом переходе. При прямом поиске по заранее известному адресу параметр допустим.

Адрес правильный, заказ изменился

Клиент спрашивает о сетевом ресурсе и добавляет параметр расширения, чтобы получить дополнительные сведения. Первый сервер возвращает HTTP-перенаправление к другой организации, располагающей полномочной записью. Базовая запись приходит, дополнительный вид ответа может пропасть. Это модель ситуации из проекта, а не сообщение о подтверждённом сбое. Указать следующий адрес — одно действие; переслать туда всё содержимое первоначального запроса — другое.

RFC 9224 определяет поиск полномочного сервиса RDAP по реестрам распределения IANA. Проект REGEXT указывает на предел такой карты: первоначальное распределение не отражает последующих передач ресурсов между региональными интернет-регистратурами. Поэтому переадресация играет практическую роль в поиске RIR, действительно отвечающего за запись. Вопрос о параметре возникает на обычном маршруте поиска, а не в редком лабораторном сценарии.

RFC 7480 требует от серверов игнорировать неизвестные параметры. Проект об расширениях добавляет правило для сервера, выпускающего новую ссылку: не переносить параметры вслепую. В них могут содержаться данные для доступа или идентификаторы отслеживания, не относящиеся к целевому серверу. Для включения параметра в URL нужно знать и способность адресата обработать его, и уместность передачи ему содержимого. Техническое понимание поля не даёт права получить его значение.

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

Прямая выдача и поиск полномочий

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

Можно переложить работу на клиент: прочитать данные в ответе перенаправления и самостоятельно собрать следующий запрос. Проект перечисляет издержки. Некоторые браузерные клиенты не видят RDAP-содержимое такого ответа. При ручной обработке нужно распознавать циклы, разрешать конфликты параметров и кодировать новый URL. Демонстрация функции на одном заранее известном сервере не доказывает её поведения на полном пути.

Карточка IETF датирует редакцию 17 27 октября 2026 года. Это действующий Internet-Draft рабочей группы REGEXT со статусом IESG «I-D Exists», пока не RFC. Правило перенаправления присутствовало и в предыдущей редакции. Значение нынешнего текста — в ясном распределении обязанностей, а не в мнимом новом запрете этой недели.

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

Источники