Кратко

  • RFC 9110 определяет Via как упорядоченную запись о прокси и шлюзах HTTP, переславших конкретное сообщение; записи могут использовать псевдонимы и при узких условиях объединяться.
  • Для заявления о полном пути нужно связать точные поля запроса и ответа с журналами входа и выхода, конфигурацией, туннелями, нижними слоями, преобразованиями и временем.

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

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

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

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

Обязанности асимметричны, причём один посредник может менять роль от запроса к запросу. Работая как прокси, он должен добавлять подходящее Via во всякое пересылаемое сообщение. Работая как шлюз HTTP–HTTP, а не как активный туннель, он должен добавлять поле во входящий запрос; в пересылаемом ответе это поле необязательно. После перехода в режим активного туннеля посредник больше не считается участником HTTP-обмена. Поэтому список ответа не обязан зеркально повторять список запроса. Сравнение количества без направления, идентификатора сообщения, текущей роли и точки наблюдения создаёт симметрию, которой стандарт не обещает.

received-by тоже не является постоянным реестром машин. Обычно это имя узла и необязательный порт, но чувствительное имя можно заменить псевдонимом. Портал на границе межсетевого экрана не должен раскрывать внутренние имена без явного разрешения. Комментарии о программном обеспечении необязательны и могут удаляться. Поле Via не аутентифицировано, поэтому токен остаётся заявлением о пересылке; участие следует подтверждать доверенной записью с контролем целостности. Сам по себе токен не определяет маршрутизируемый адрес, машину, процесс или организацию-оператора.

Даже длина списка требует контекста. RFC 9110 разрешает объединить упорядоченную подпоследовательность только тогда, когда её элементы имеют одинаковое значение received-protocol; но и в этом случае отправителю следует отказаться от объединения, если элементы вдобавок не находятся под единым организационным управлением или их имена узлов ещё не заменены псевдонимами. Элементы с разными протоколами приёма объединять нельзя. В совокупности эти условия сохраняют границы возможностей протокола и допускают сжатие лишь управляемой, псевдонимизированной внутренней топологии. Поэтому один видимый элемент может описывать нескольких участников пересылки.

Преобразования составляют отдельную плоскость доказательств. Прокси может менять поля или содержимое. Шлюз может переводить между HTTP и частным протоколом. Туннель переносит зашифрованные байты, не раскрывая прикладные сообщения и внутренние ретрансляторы. Via фиксирует участие в HTTP-пересылке, но не полностью приписывает изменения, кэширование, проверку безопасности, балансировку или физические линии.

Надёжный журнал прохождения сообщения должен сохранять идентификаторы запроса и ответа, исходные значения Via во всех точках наблюдения, протокол и направление, соответствие псевдонимов управляемым посредникам, правила объединения, время входа и выхода, решения кэша и преобразования, концы туннеля и наблюдения нижних уровней. «Не видно в Via» следует отличать от «нет в пути». Такой журнал — редакционный операционный синтез, а не объект протокола IETF.

Эта граница отделяет тему от соседних. Временные адреса IPv6 касаются корреляции после смены идентификатора. BFD касается ограниченной проверки живости и выбора маршрута. HTTP Priority касается того, изменил ли приоритет порядок и сроки доставки. Via касается происхождения и полноты записи о пересылке сообщения.

Источники