Поле Transfer-Encoding (Транспортное кодирование)

Поле общего заголовка Transfer-Encoding указывает, какой тип преобразования (если таковое использовано) применен к телу сообщения, чтобы безопасно осуществить передачу между отправителем и получателем. Это поле отличается от Content-Encoding тем, что транспортное кодирование является параметром сообщения, а не объекта.

Transfer-Encoding = "Transfer-Encoding" ":" 1#transfercoding

Например:

Transfer-Encoding: chunked

Многие старые приложения HTTP/1.0 не воспринимают заголовок Transfer-Encoding.

Заголовок Upgrade (Актуализация)

Общий заголовок Upgrade позволяет клиенту специфицировать, какие дополнительные коммуникационные протоколы он поддерживает и хотел бы использовать, если сервер найдет их подходящими. Сервер должен применять поле заголовка Upgrade в отклике 101 (Switching Protocols) для указания, какие протоколы активны.

Upgrade = "Upgrade" ":" 1#product

Например:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Поле заголовка Upgrade предназначено для обеспечения простого механизма перехода от протокола HTTP/1.1 к некоторым другим. Клиенту разрешается объявлять о намерении использовать другой протокол, например, более позднюю версию HTTP с большим старшим кодом версии, даже если текущий запрос выполнен с использованием HTTP/1.1. Это облегчает переходы между несовместимыми протоколами за счет разрешения клиенту инициировать запрос в более широко поддерживаемом протоколе, и в то же время, указывая серверу, что он предпочел бы использовать протокол получше, если таковой доступен (где понятие "получше" определяется сервером, возможно, согласно природы метода и/или запрашиваемого ресурса).

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

Поле Upgrade применимо только к текущему соединению. Следовательно, ключевое слово upgrade должно содержаться в поле заголовка Connection всякий раз, когда поле Upgrade присутствует в сообщении HTTP/1.1.

Поле заголовка Upgrade не может использоваться для указания смены протокола в другом соединении. Для этой цели более приемлемы отклики переадресации с кодами 301, 302, 303 или 305.

Данная спецификация определяет протокол с именем HTTP при работе с семейством протоколов для передачи гипертекста (Hypertext Transfer Protocols), как это определено в правилах работы с версиями HTTP и для будущих усовершенствований этой спецификации.

Поле User-Agent (Агент пользователя)

Поле заголовка отклика User-Agent содержит информацию о программе­агенте пользователя, инициировавшем запрос. Это нужно для целей сбора статистических данных, отслеживания нарушений протокола и автоматического распознавания агентов пользователя. Агентам пользователя рекомендуется включать это поле в запросы. Поле может содержать несколько кодов продуктов, комментарии, идентифицирующие агента, и любые субпродукты, которые образуют существенную часть агента пользователя. Согласно договоренности, коды программных продуктов перечисляются в порядке их важности для идентифицируемого приложения.

User-Agent = "User-Agent" ":" 1*(product | comment)

Например:

User-Agent: CERNLineMode/2.15 libwww/2.17b3

Поле Vary

Поле заголовка отклика Vary используется сервером, чтобы сигнализировать о том, что отклик выбран из числа имеющихся представлений с помощью механизма согласования под управлением сервера. Значение поля Vary указывает на то, что данный набор полей заголовка ограничивает пределы, в которых могут варьироваться представления, или что пределы вариации не специфицированы ("*") и, таким образом, могут модифицироваться в широких пределах для будущих запросов.

Vary = "Vary" ":" ("*" | 1#fieldname)

Сервер HTTP/1.1 должен включать соответствующее поле заголовка Vary в любой кэшируемый отклик, который является субъектом, управляющим процессом согласования. Такая схема позволяет кэшу правильно интерпретировать будущие запросы к заданному ресурсу и информирует пользователя о согласовании доступа к ресурсу. Серверу следует включить соответствующее поле заголовка Vary в некэшируемый отклик, который является субъектом, управляющим согласованием, так как это может предоставить агенту пользователя полезную информацию о пределах вариации отклика.

Набор полей заголовка, перечисленных в поле Vary, известен как выбирающие заголовки запроса.

Когда кэш получает последующий запрос, чей Request-URI специфицирует одну или более записей кэша, включая заголовок Vary, кэш не должен использовать такую запись для формирования отклика на новый запрос. Он это должен делать, если только все заголовки, перечисленные в кэшированном заголовке Vary, присутствуют в новом запросе и все заголовки предшествующих запросов совпадают с соответствующими заголовками нового запроса.

Сортирующие заголовки от двух запросов считаются соответствующими тогда и только тогда, когда сортирующие заголовки первого запроса могут быть преобразованы в сортирующие заголовки второго запроса с помощью добавления или удаления строчных пробелов LWS (Linear White Space) в местах, где это допускается соответствующими правилами BNF (BackusNaur Form), и/или комбинируя несколько полей заголовка.

Vary "*" означает, что не специфицированные параметры, возможно отличающиеся от содержащихся в полях заголовка (например, сетевой адрес клиента), играют роль при выборе представления отклика. Последующие запросы данного ресурса могут быть правильно интерпретированы только исходным сервером, а кэш должен переадресовать запрос (возможно, условно), даже когда он имеет свежий кэшированный отклик для данного ресурса.

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

Имена полей не ограничены набором стандартных полей заголовков запросов, определенных в данной спецификации. Имена полей могут быть записаны строчными или прописными буквами.

Поле Via

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

Via = "Via" ":" 1#(receivedprotocol receivedby [ comment ])
receivedprotocol = [ protocolname "/" ] protocolversion
protocolname = token
protocolversion = token
receivedby = (host [ ":" port ]) | pseudonym
Pseudonym = token

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

Запись protocolname является опционной тогда и только тогда, когда это протокол HTTP. Поле receivedby обычно соответствует ЭВМ и номеру порта сервера получателя или клиента, который переадресует сообщение. Однако если настоящее имя ЭВМ считается конфиденциальной информацией, оно может быть заменено псевдонимом. Если номер порта не задан, можно предполагать, что используется значение по умолчанию для данного протокола (receivedprotocol).

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

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

Например, сообщение­запрос может быть послано от агента пользователя HTTP/1.0 программе внутреннего прокси с именем fred — она применяет HTTP/1.1 для того, чтобы переадресовать запрос общедоступному прокси с именем nowhere.com, который завершает процесс переадресации запроса исходному серверу www.ics.uci.edu. Запрос, полученный www.ics.uci.edu, будет тогда иметь следующее поле заголовка Via:

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

Прокси и шлюзы, используемые как средства сетевой защиты (firewall) не должны по умолчанию переадресовывать имена ЭВМ и портов в пределах области firewall. Эта информация может передаваться, если это позволено непосредственно. Если это не разрешено, запись receivedby для ЭВМ в зоне действия firewall должна быть заменена соответствующим псевдонимом.

Для организаций, которые имеют жесткие требования к защите конфиденциальности и сокрытию внутренней структуры, прокси может комбинировать субпоследовательность поля заголовка Via с идентичными значениями receivedprotocol в единую запись. Например,

Via: 1.0 vanya, 1.1 manya, 1.1 dunya, 1.0 sonya

Приложениям не следует комбинировать несколько записей, если они только не находятся под единым административным контролем и имена ЭВМ уже заменены на псевдонимы. Приложения не должны комбинировать записи, которые имеют различные значения receivedprotocol.