RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

14.44. Via

Общее поле заголовка Via ДОЛЖНО использоваться шлюзами и прокси, чтобы указать промежуточные протоколы и получателей между user agent и сервером на запросах, и между сервером происхождения и клиентом на ответах. Он походит на поле "Received" RFC 822 и предназначен, чтобы использоваться для того, чтобы проследить сообщение, пересылают, избегая циклов запроса, и идентифицируя возможности протокола всех отправителей вдоль цепочки запроса/ответа.

Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
protocol-name     = token
protocol-version  = token
received-by       = ( host [ ":" port ] ) | pseudonym
pseudonym         = token

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

protocol-name является опциональным, если и только если он был бы "HTTP". Поле received-by обычно — ведущее и опциональное число port сервера получателя или клиента, который впоследствии отправлял сообщение. Однако, если реальный хост рассматривается, чтобы быть секретной информацией, он МОЖЕТ быть заменен псевдонимом. Если port не дан, он МОЖЕТ быть предположен, чтобы быть значением по умолчанию port received-protocol.

Множественные значения поля Via представляют каждый прокси или шлюз, который отправил сообщение. Каждый получатель ДОЛЖЕН добавить его информацию таким образом, что исход упорядочен согласно последовательности пересылки приложений.

Комментарии МОГУТ использоваться в поле заголовка Via, чтобы идентифицировать программное обеспечение прокси получателя или шлюза, аналогичного полям заголовка Server и User-Agent. Однако, все комментарии в поле Via являются опциональными и МОГУТ быть удалены любым получателем до пересылки сообщения.

Например, сообщение запроса можно было отправить от HTTP/1.0 user agent к внутреннему прокси "Фреда" под кодовым названием, который использует HTTP/1.1, чтобы отправить запрос прокси public в nowhere.com, который завершает запрос, отправляя его серверу происхождения в www.ics.uci.edu.

У запроса, полученного www.ics.uci.edu, тогда было бы следующее поле заголовка Via:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Прокси и шлюзы, используемые как портал через сетевую межсетевую защиту, не ДОЛЖНЫ, по умолчанию, отправить имена и порты хостов в пределах области межсетевой защиты. Эта информация ДОЛЖНА только быть распространена если явно допущено. Если не допущенный, хост received-by какого-нибудь хоста позади межсетевой защиты ДОЛЖЕН быть заменен соответствующим псевдонимом для того хоста.

Для организаций, у которых есть сильные требования частной жизни сокрытия внутренних структур, прокси МОЖЕТ объединить упорядоченную подпоследовательность входов поля заголовка Via с идентичными значениями received-protocol в отдельное такой элемент. Например,

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

 мог быть сокращен к

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

Приложения не ДОЛЖНЫ объединить множественные входы, если они не все под тем же самым организационным управлением, и хосты были уже заменены псевдонимами. Приложения не ДОЛЖНЫ объединить входы, у которых есть другие значения received-protocol.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.