Гипертекстный протокол HTTP

Приложения

1. Интернетовский тип среды message/http

В дополнение к определению протокола HTTP/1.1, данный документ является спецификацией для типов среды Интернет message/http. Ниже приведенный список является официальным для IANA.

Media Type name:    message
Media subtype name:    http
Required parameters:  none
Optional parameters:  version, msgtype

version: Номер версии HTTP вложенного сообщения (напр., 1.1). Если отсутствует, номер версии может быть определен по первой строке тела сообщения.

msgtype: Тип сообщения — запроса или отклика. Если отсутствует, тип может быть определен по первой строке тела сообщения.

Соображения кодирования: разрешено только 7bit, 8bit или binary (двоичное).

2. Тип среды Интернет multipart/byteranges

Когда сообщение HTTP содержит несколько фрагментов (например, отклик на запрос нескольких неперекрывающихся фрагментов), они пересылаются как многофрагментное сообщение MIME. Тип среды multipart для этих целей носит название multipart/byteranges.

Тип среды multipart/byteranges содержит в себе две или более части, каждая из которых — со своими полями Content-Type и ContentRange. Отдельные части разделяются с использованием пограничного параметра MIME.

Media Type name:    multipart
Media subtype name:    byteranges
Required parameters:  boundary
Optional parameters:  none

Соображения кодирования: разрешено только 7-bit, 8-bit или binary.

Например:

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Lastmodified: Wed, 15 Nov 1995 04:58:08 GMT Contenttype: 
   multipart/byteranges; 
     boundary=THIS_STRING_SEPARATES—THIS_STRING_SEPARATES
Contenttype: application/pdf
Contentrange: bytes 500999/8000
...первый фрагмент…
THIS_STRING_SEPARATES
Contenttype: application/pdf
Contentrange: bytes 70007999/8000
второй фрагмент...
THIS_STRING_SEPARATES—

3. Толерантные приложения

Хотя этот документ специфицирует требования к генерации HTTP/1.1 сообщений, не все приложения будут корректны. Рекомендуеется, чтобы рабочие приложения были толерантны (терпимы) к некоторым отклонениям от требований, при условии, что эти отклонения можно однозначно интерпретировать. Клиенту следует быть толерантным при разборе StatusLine, а серверу — при разборе RequestLine. В частности, им следует воспринимать любое число символов SP или HT между полями, хотя требуется только один пробел ( SP ). Терминатором строки полей заголовков сообщения является CRLF. Однако рекомендуется, чтобы приложение при разборе таких заголовков распознавало в качестве терминатора строки одиночный символ LF и игнорировала предыдущий символ CR. Символьный набор тела объекта должен быть снабжен меткой. Метка не нужна только для набора US-ASCII или ISO-88591. Правила разбора и кодирования дат и пр. включают в себя предположение для HTTP/1.1 клиентов и кэшей, что даты, следующие документу RFC-850 и относящиеся ко времени 50 лет в будущем, на самом деле относятся к прошлому.

• Приложение HTTP/1.1 может внутри представлять время истечения годности раньше, чем истинное значение, но не должно представлять его позднее истинного значения.
• Все вычисления, относящиеся ко времени пригодности, должны выполняться в шкале GMT (по Гринвичу). Местные временные зоны не должны оказывать влияния на вычисления и сравнение возраста и времени пригодности.

Если заголовок HTTP несет в себе некорректное значение даты с временной зоной, отличной от GMT, значение должно быть преобразовано в GMT.

4. Различие между объектами HTTP и MIME

HTTP/1.1 использует много конструкций, определенных для электронной почты Интернет (RFC-822) и MIME (Multipurpose Internet Mail Extensions), для обеспечения пересылки объектов в различных представлениях. MIME [7.7] обслуживает электронную почту, а HTTP имеет лишь ряд черт, которые отличают его от MIME. Эти отличия тщательно подобраны, чтобы оптимизировать работу в условиях двоичных соединений ради большей свободы в использовании новых типов сред. Прокси и шлюзы должны по возможности исключать такие отличия и обеспечивать соответствующие преобразования там, где это нужно.

Преобразование к канонической форме

MIME требует, чтобы почтовый объект Интернет перед посылкой был преобразован в каноническую форму. MIME требует, чтобы содержимое типа text представляло разрывы строк в виде последовательности символов CRLF, и запрещает использование CR или LF отдельно. Для обозначения разрыва строки HTTP позволяет использовать CRLF, одиночный CR и одиночный LF. Всюду, где возможно, прокси и шлюзы между средами HTTP и MIME должны преобразовать все разрывы строк для текстовых типов среды. Заметьте, однако, что это может вызвать сложности в присутствии кодирования содержимого, а также вследствие того, что HTTP допускает применение символьных наборов, которые не используют октеты 13 и 10 для представления CR и LF, так как для этих целей здесь служат многобайтовые последовательности.

Чтобы упростить сравнение, HTTP/1.1 использует ограниченный набор форматов даты. Прокси и шлюзы должны позаботиться о преобразовании полей заголовков даты в один из допустимых форматов всякий раз, когда это необходимо (при получении данных от других протоколов).

Введение кодирования содержимого

MIME не содержит какоголибо эквивалента полю заголовка Content-Encoding HTTP/1.1. Так как это поле работает как модификатор типа среды, прокси и шлюзы между HTTP и MIME протоколами должны или изменить значение поля заголовка Content-Type, или декодировать тело объекта, прежде чем переадресовывать сообщение. Некоторые экспериментальные приложения Content-Type для почты Интернет используют параметр типа среды ";conversions=" для выполнения операции, аналогичной Content-Encoding. Однако этот параметр не является частью MIME.

No Content-Transfer-Encoding

HTTP не использует поле MIME CTE (Content-Transfer-Encoding). Прокси и шлюзы от MIME к HTTP должны удалять любую неидентичность CTE (quoted-printable или base64) кодирования, прежде чем доставлять сообщение­отклик клиенту HTTP.

Прокси и шлюзы от HTTP к MIME ответственны за то, чтобы сообщения имели корректные форматы и кодировки для безопасной транспортировки (безопасная транспортировка определяется ограничениями используемого протокола). Такие прокси и шлюзы должны помечать информацию согласно Content-Transfer-Encoding. Поступая так, мы улучшаем вероятность безопасной транспортировки с применением протокола места назначения.

Поля заголовка в многофрагментных телах

В MIME большинство полей заголовка в многофрагментных частях игнорируются, если только имя поля не начинается с Content. В HTTP/1.1 многофрагментные части тела могут содержать любые поля заголовков HTTP, которые имеют смысл для этой части.

Введение транспортного кодирования

Протокол HTTP/1.1 вводит поле заголовка Transfer-Encoding. Прокси/шлюзы должны удалять любое транспортное кодирование перед переадресацией сообщения через протокол MIME.

Процесс декодирования транспортного кода может быть представлен в виде псевдопрограммы:

length := 0
read chunksize, chunkextention (if any) and CRLF
while (chunksize > 0) {
read chunkdata and CRLF
append chunkdata to entitybody
length := length + chunksize
read chunksize and CRLF
}
read entityheader
while (entityheader not empty) {
append entityheader to existing header fields
read entityheader
}
ContentLength := length
Remove "chunked" from Transfer-Encoding

MIME-Version

HTTP не является протоколом, совместимым с MIME. Однако HTTP/1.1 сообщения могут включать поле общего заголовка MIME-Version, чтобы указать, какая версия протокола MIME была использована для конструирования сообщения. Использование заголовка поля MIME-Version отмечает, что сообщение полностью соответствует протоколу MIME. Прокси/шлюзы несут ответственность за полную совместимость (где это возможно), когда осуществляется передача HTTP сообщений в среду MIME.

MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Дополнительные методы запросов

Метод PATCH

Метод PATCH подобен PUT, за исключением того, что объект содержит список отличий между оригинальной версией ресурса, идентифицированного Request-URI, и желательной версией ресурса после операции PATCH. Список отличий записывается в формате, определенном типом среды объекта (например, application/diff), и должен включать достаточную информацию, чтобы позволить серверу выполнить изменения по преобразованию ресурса из исходной версии в заказанную.

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

Реальный метод определения того, как разместится скорректированный ресурс и что случится с его предшественником, определяется исключительно исходным сервером. Если оригинальная версия ресурса, который предполагается скорректировать, включает в себя поле заголовка Content-Version, объект запроса должен включать поле заголовка Derived-From, соответствующее значению оригинального поля заголовка Content-Version. Приложениям рекомендуется использовать эти поля для работы с версиями с целью разрешения соответствующих конфликтов. Запросы PATCH должны подчиняться требованиям к передаче сообщений. Кэши, которые реализуют PATCH, должны объявить кэшированные отклики недействительными.

Метод LINK

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

Определения дополнительных полей заголовка

Поле Alternates

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

Поле Content-Version

Поле заголовка объекта Content-Version определяет метку версии, ассоциированную с отображением объекта. Вместе с полем Derived-From, это позволяет группе людей вести разработку в интерактивном режиме.

Content-Version = "Content-Version" ":" quotedstring.

Примеры использования поля Content-Version:

Content-Version: "1.3.1"
Content-Version: "Fred 1895011511:25:39"
Content-Version: "2.6b4omega8"

Поле Derived-From

Поле заголовка объекта Derived-From может использоваться для индикации метки версии ресурса, из которого был извлечен объект до модификации, выполненной отправителем. Это поле применяется для того, чтобы помочь управлять процессом эволюции ресурса, в частности, когда изменения выполняются параллельно многими субъектами.

Derived-From = "Derived-From" ":" quotedstring.

Пример использования поля:

Derived-From: "1.1.1".

Поле Derived-From необходимо для запросов PUT и PATCH, если посланный объект был перед этим извлечен из того же URI и заголовок Content-Version был включен в объект, когда он последний раз извлекался.

Поле Link

Поле заголовка объекта Link предоставляет средства для описания взаимоотношений между ресурсами. Объект может включать много значений поля Link. Связи на уровне метаинформации обычно указывают на отношения типа структуры иерархии и пути прохода. Поле Link семантически эквивалентно элементу в HTML [7.5].

Link      = "Link" ":"#("<" URI ">" *(";" linkparam)
linkparam    = (("rel" "=" relationship )
        | ("rev" "=" relationship)
        | ( 'title" "=" quotedstring )
        | ( "anchor" "=" <"> URI <"> )
        | (linkextension ))
linkextension  = token ["=" (token | quotedstring )]
Relationship  = sgmlname
        | ( <"> sgmlname *( SP sgmlname) <"> )
sgmlname    = ALPHA *( ALPHA | DIGIT | "." | "")

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

Link: ; rel="Previous"
Link: ; rev="Made"; title="Tim BernersLee"

Первый пример указывает, что глава 2 предшествует данному ресурсу с точки зрения логического прохода. Второй демонстрирует, что лицо, ответственное за данный ресурс, имеет приведенный адрес электронной почты.

Система проксисерверов приобрела всемирный характер и главная ее задача — минимизация транзитного трафика. Но часто может возникать ситуация, когда требующийся объект содержится в проки­сервере, размещенном неподалеку, но не вдоль маршрута к исходному серверу. В этом случае запрос будет послан исходному серверу, что может создать дополнительную загрузку в большом числе внешних каналов. Представляется целесообразным обмен данными между прокси о заголовках объектов, хранящихся там. Такая информация может существенно снизить транзитный трафик. Можно попытаться изменить протокол так, чтобы объекты размещались в тех прокси, для которых среднеквадратичные расстояние до совокупности клиентов, запрашивавших этот ресурс, было минимальным.