Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

220

Часть

III. Web-протоколы

паутина стала частью образа жизни миллионов людей, быстро развивалась элек-

тронная торговля.

К сожалению, некоторые из архитектурных решений, принятых в НТТР/1.0,

имели неблагоприятные побочные эффекты. Например, одна из проблем заключа-

лась в том, что протокол прикладного уровня HTTP работал поверх наиболее рас-

пространенного протокола транспортного уровня TCP. Хотя TCP считали одним

из лучших транспортных протоколов еще на начальной стадии развития Web, даже

первоначальная версия HTTP, НТТР/0.9, не требовала использования TCP. Ста-

тья 1992 г., в которой описывалось то, что позже стало известно как НТТР/0.9

[BL92aJ, включала, в частности, следующий фрагмент:

Примечание. В настоящее время HTTP работает поверх TCP, но сможет ра-

ботать поверх любого транспортного протокола, ориентированного на соеди-

нения.

Так как TCP являлся основным транспортным протоколом с начала 1980-х го-

дов,

не удивительно, что фактически все реализации HTTP работали поверх TCP.

Однако TCP не был оптимизирован для передачи коротких сообщений; большинст-

во Web-данных на рагнтей стадии развития Web (около 1994 г.) представляли со-

бой файлы объемом менее 10 Кб [ВС94]. В этом разделе мы познакомимся с пол-

ным списком такого рода проблем в НТТР/1.0.

Мы начнем с истории эволюции НТТР/1.1 и рассмотрения процесса стандарти-

зации протоколов организацией Internet Engineering Task Force (IETF). Затем мы

рассмотрим проблемы, связанные с НТТР/1.0, которые привели к появлению

НТТР/1.1.

Далее исследуется новые концепции, внесенные в НТТР/1.1.

7.1.1.

История развития НТТР/1.0

С января 1995 г. по июнь 1999 г. HTTP Working Group прилагала значительные

усилия для решения проблем, связанных с НТТР/1.0. За четыре с лишним года

эволюции от НТТР/1.0 до НТТР/1.1 вышло несколько версий документов для

этого протокола. Дискуссии в HTTP Working Group за этот период досту1Н1Ы в он-

лайновом архиве [WG-99J. Некоторые из основных изменений протокола, сделан-

ные в результате этих дискуссий, обсуждаются в статье [КМК99]. Движущей си-

лой развития протокола было влияние, оказагнюе НТТР/1.0 на Internet на началь-

ном этапе, и желание реализовать новые возможности, основываясь на опыте

разработчиков различных Web-KOMHOiienTOB. Взрыв популярности Web пришелся

Ихменгю на этот период.

Переход от НТТР/1.0 к НТТР/1.1 не был ни гладким, ни простым. Некоторые

разработчики браузеров и серверов включали в свои продукты возможности, кото-

рые не соответствовали общепринятой практике применения HTTP 1.0, по ним не

было достигнуто согласия в процессе дискуссий в HTTP Working Group. Как толь-

ко новые возможности становились частью повседневной практики, па повестке

дня в Working Group вставал вопрос об обратной совместимости. Источником

многих известных проблем с НТТР/1.1 являлось как раз обеспечение обратной со-

вместимости и ограниченные возможности расширения НТТР/1.0. Тем не менее,

протокол все же проделал значительный путь эволюции, на котором было разреше-

но большое число проблем.

Многие браузеры и прокси-серверы остаются по-прежнему несовместимыми

с НТТР/1.1. На группу разработки стандарта HTTP оказывалось значительное

давление, связанное с коммерческими интересами, а не с техническими вопросами.

Глава 7. HTTP/1.1 221

Несколько известных компаний являлись владельцами популярных продуктов.

Корпорации, которые были заинтересованы в сохранении определенных возможно-

стей или в продвижении своего подхода, открыто заявляли о своих особых интере-

сах. И все же процесс совершенствования протокола был завершен таким образом,

что ни одна из частных компаний не смогла навязать свою особую точку зрения

всему Web-сообществу. Даже в тех случаях, когда большая часть рынка принадле-

жит одному продукту, окончательная версия протокола не выглядит попавшей под

влияние решений, реализованных в этом продукте. Одной из причин этого являет-

ся процедура работы над протоколами в IETF, в основе которой лежит достижение

общего согласия. Другая причина

—

это усилия HTTP Working Group. Однако су-

ществующие реализации оказывали влияние на введение некоторых новых воз-

можностей. Одним из примеров является возможность осуществлять запросы на

диапазоны данных, что будет рассмотрено в разделе

7.4.1.

Существующие реализа-

ции оказали также существенное влияние на проблему управления состоянием

в HTTP [KMOOJ.

Попытки стандартизации или модернизации любого протокола проходят через

ряд последовательных этапов; детальное описание этого процесса представлено

в RFC 2026 [Bra96bJ.

Проект документа (Internet Draft) готовится и затем обсуждается с использо-

ванием электронных средств информации и на совещаниях, проводимых

IETF три раза в год. Проект документа публикуется в электронном виде на

Web-сайте IETF.

Исполнительный комитет IETF (IESG

—

Internet Engineering Steering Group)

может отнести проект документа к одной из трех категорий: информацион-

ной, экспериментальной или стандартам. Если IESG одобряет проект доку-

мента, то последний становится официальным документом RFC (Request For

Comment) и ему присваивается номер. Информационтлй докуме1гг не дол-

жен рассматриваться ни в качестве руководства при реализации, ни в качест-

ве стандарта. Например, документ RFC 1945, в котором описана структура

НТТР/1.0, относится к категории информационных документов. Аналогич-

ным образом, спецификация нового протокола Internet Printing Protocol

(IPP),

описанная в RFC 2565 [HBMT99J, относится к категории эксперимен-

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

нескольких версий проекта документа.

Проект документа в процессе разработки стандарта проходит через три этана:

предложение по стандарту (Proposed Standard), проект стандарта (Draft

Standard) и стандарт Internet (Internet Standard). Предложение по стандар-

ту

—

это первая ступенька на пути к спецификации протокола, предложение

должно иметь ясную структуру, апробированную сообществом, но ни реали-

зация, ни практическое применение не являются на этом этапе обязателын>1-

ми.

Проект стандарта должен иметь как минимум две совместимые между со-

бой реализации, разработанные независимо друг от друга. Эти реализации

должны включать в себя различные возможности спецификации с тем, чтобы

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

проекта стандарта. Наконец, спецификация достигает статуса стандарта In-

ternet после продолжительного тестирования и общего признания полезно-

сти этой спецификации для Internet-сообщества. Такой спецификации при-

сваивается и номер RFC, и номер в отдельной серии документов, называемых

STD (сокращение от Standard). На каждом этапе стандартизации отводится

некоторое время на получение отзывов и комментариев от Internet-сообщест-

222 Часть III. Web-протоколы

ва. Предложение по стандарту должно минимум шесть месяцев оставаться па

данной стадии, прежде чем осуществляется переход па уровень проекта стан-

дарта, хотя этот период может продолжаться значительно дольше. На уровне

проекта стандарта документ должен находиться четыре месяца или, по мень-

lueii мере, до следующего заседания IETF (независимо от срока), прежде чем

можно будет перейти к этапу стандарта Internet.

Процесс эволюции протокола HTTP был осложнен появлением промежуточного

документа — предложения по стандарту RFC 2068 [ЕОМ^97|, в котором было за-

фиксировано состояние дискуссий по НТТР/1.1 на то время. К сожалению, доку-

мент, представленный на рассмотрение в качестве предложения по стандарту

НТТР/1.1,

обсуждался дольше, чем обычгю, и был принят в качестве предложения

по стандарту только в январе 1997 г. Частично из-за неудачного стечения обстоя-

тельств, появление большинства новых версий браузеров совпа;ю по времени с по-

явлением RFC 2068. Вскоре некоторые реализации клиентов и серверов в общем и

целом совместимые со спецификацией, описанной в RFC 2068, стали претендовать

на то, чтобы считаться совместимыми НТТР/1.1, хотя спецификация протокола

НТТР/1.1 была всего лишь па этапе предложения по стандарту, а не стандарта

Internet. Этот номер версии быстро стал притчей во языцех, поскольку Web-серверы

претендовали на то, что они реализуют «стандарт» НТТР/1.1, который в то время не

существовал (и не существует на момент публикации этой книги). Таким образом,

хотя спецификация вскрыла существующие проблемы (и зафиксировала их в разде-

ле 19.6.3 RFC 2616), программное обеспечение, реализующее спецификацию, изме-

нялось не так быстро. Тем не менее, появление RFC 2068 послужило поводом для

тес'гирования различных программных компонентов, реализующих спецификацию.

Таким образом, усилия по стандартизации протокола НТТР/1.1 усугублялись

дополнительными проблемами, связанными с обеспечением совместимости с брау-

зерами и серверами, реализующими RFC 2068. Проект стандарта RFC 2616

[FGM'99J вышел в июне 1999 г. Предполагалось, что этот проект станет официаль-

ным стандартом Internet в 2001. Одна из причин задержки заключается в том, что

стандарт IETF не может быть оформлен официально до тех пор, пока из пего не

будут удалены «ненормативные» ссылки. В случае с НТТР/1.1 это ссылка на

Ml ME ^E-mail Encapsulation (MHTML, RFC 2110 [PH97]), документ который впо-

следствии был заменен документом RFC 2557 [PH99J.

7.1.2. Проблемы, связанные с НТТР/1.0

Считалось необходимым изменить НТТР/1.0 в различных областях.

В RFC 2616 (в разделе 19.6.1) перечислено несколько изменений в НТТР/1.1 по

сравнению с НТТР/1.0. Более обширный список отличий был представлен в рабо-

те IKMK99J, здесь используется расширенная версия этой систематики. Полный

список проблем, связанных с НТТР/1.0, можно представить следующим образом:

• Отсутствие возможностей управления продолжительностью кэширования,

местОхМ кэширования и вариантами специальных запросов и ответов для кэ-

инфования.

• Загрузка всего содержимого ресурса, в то время как нужна только небольшая его

часть и отсутствие возможности возобновления прерванной передачи данных.

• Недостатки использования в TCP для коротких ответов, типичных для Web.

• Отсутствие гарантии полного получения динамически генерируемых ответов.

Глава

HTTP/1.1

223

• Проблемы расширяемости и отсутствие возможности получать информацию о

промежуточных серверах.

• Сокращение резерва IP-адресов из-за привлекательности высокоуровневых

доменных имен для Web-бизнеса.

• Неспособность принимать во внимание предпочтения клиентов и серверов и

соответственно изменять сообщения запросов и ответов.

• Недостаточность средств защиты при быстро растущих потребностях в защи-

щенных взаимодействиях в Web, а также использование в основной схеме ау-

тентификации, принятой в HTTP/1.0, передачи паролей открытым текстом.

• Неопределенность правил взаимодействия с прокси-серверами и кэшами.

• Разнообразные проблемы, связанные с различными методами, заголовками и

кодами ответов.

Значительное увеличение общих задержек в сети, увеличение воспринимаемой

пользователем задержки отклика и повышение интереса к безопасности выявили

некоторые из проблем, связанных с HTTP/1.0. В некоторых случаях стали исполь-

зоваться альтернативные средства (например, протокол Secure Socket Layer [SSL]

обеспечивает защищенную передачу данных). Однако важные проблемы остава-

лись нерешенными. Группа HTTP Working Group реализовала несколько усовер-

шенствований, уделив внимание правильному применению уровней требований

(согласно RFC 2119 [ВгаЭба]), устранив специфические зависимости от TCP как

единственного для HTTP протокола транспортного уровня и удалив практически

не используемые методы (рассмотренные в приложении к RFC 1945).

7.1.3.

Новые концепции в НТТР/1.1

Кроме попыток решить известные проблемы НТТР/1.0, в НТТР/1.1 были пред-

ложены и некоторые новые концепции. Основными концепциями, предложенными

для усовершенствования протокола, были следующие:

• Механизм промежуточных передач (hop-by-hop).

• Кодирование при передаче.

• Виртуальный хостинг.

• Обеспечение семантической прозрачности кэширования.

• Поддержка ресурсов, представленных в нескольких вариантах.

В этом разделе мы рассмотрим первые две концепции: механизм промежуточ-

ных передач и кодирования при передаче. Эти две идеи широко используются при

обмене сообщениями по протоколу HTTP. Другие возможности имеют более огра-

ниченный характер и обсуждаются в последующих разделах. Виртуальный хос-

тинг, обсуждаемый в разделе 7.8, предоставляет возможность нескольким Web-сер-

верам функционировать на одном компьютере, не требуя при этом отдельного

IP-адреса для каждого сервера. Поддержка семантической прозрачности стала

в НТТР/1.1 приоритетным вопросом. Прокси-сервер, осуществляющий кэширова-

ние,

при получении запроса от клиента не может вернуть ответ из своего кэша, не

проверив его актуальности. Поскольку ресурсы, размещенные на Web-серверах,

могут быть представлены в различных вариантах для конкретных клиентов (на-

пример, на различных языках, с использованием специфических наборов симво-

лов),

необходимо было обеспечить выборку из кэша гюдходящего варианта. Под-

224 Часть HI. Web-протоколы

держка семантической прозрачности и управление вариантами содержания были

добавлены в НТТР/1.1 и подробно обсуждаются в разделе 7.3.3.

МЕХАНИЗМ ПРОМЕЖУТОЧНЫХ ПЕРЕДАЧ

С точки зрения пользователя Web-серверу посылается запрос, а агенту пользо-

вателя возвращается ответ. Это обобщенное представление Web-транзакции. На

самом деле это не всегда так, из-за наличия кэшей и прокси-серверов на пути тран-

закции. HTTP-сообщение может проходить через несколько промежуточных серве-

ров.

Заголовки НТТР/1.0 посылаются от отправителя получателю и от получателя

отправителю. Предполагается, что промежуточные прокси-серверы, если они не

воспринимают поля заголовков, просто пересылают сообщения дальше (этот мо-

мент особо выделен в разделе 7.1 RFC 1945 и в RFC 2616).

В условиях широкого распространения прокси-серверов в Web возможно, что два

соседних промежуточных звена могли бы использовать ajmrepnaTHBHbie способы об-

мена HTTP-сообщениями. Например, они могут использовать а^агоритмы сжатия,

недоступные другим компонентам в цепочке обмена сообщениями. Эти соседние

звенья должны будут включать в заголовки снециа7нэные метаданные, отражающие

их особые возможности. Однако такие заголовки не смогут быть переданы дальше

по цепочке, так как другие получатели на пути от источника к получателю могут не

воспринимать те специфические возможности, которыми располагает указанная

пара. Становится необходимым механизм, посредством которого произвольный на-

бор заголовков можно было бы надежно пересылать только определенным промежу-

точным звеньям. Это приводит к введению заголовков нромежуточгшгх передач, ко-

торые действуют только в одном соединении транснорпюго уровня. Заголовок

Transfer-Encoding, введенный в НТТР/1.1, первоначально появился, чтобы обеспе-

чить сжатие данных на промежуточных участках передачи [Fie97j. Заголовки проме-

жуточных передач не могут сохраняться в кэше или передаваться по цепочке про-

кси-серверами. Получатель заголовков промежуточных передач изымает их, прежде

чем передавать сообщение далее. Промежуточные серверы удаляют заголовки про-

межуточных передач и могут добавлять новые. НТТР/1.1 использует новый заголо-

вок Connection для перечисления заголовков, которые должны восприниматься как

заголовки промежуточных передач, то есть заголовки, предназначенные только для

одного этого соединения, а не для передачи по цепочке. Например,

Connection: header 1, header2

означает, что сервер, получивший данное сообщение, должен удалить заголовки

headerl и header2, прежде чем передавать это сообщение дальше.

Понимание механизма промежуточных передач необходимо для ответа на во-

прос о том, какая доля сетевого трафика использует НТТР/1.1. Недостаточно про-

верить, что клиент и Web-сервер поддерживают НТТР/1.1. Если промежуточные

серверы между клиентом и Web-сервером не используют НТТР/1.1, то версия со-

общения обычно понижается до предыдущей версии HTTP. Таким образом, сквоз-

ной трафик может и не соответствовать НТТР/1.1.

КОДИРОВАНИЕ ПРИ ПЕРЕДАЧЕ

В НТТР/1.1 понятие содержимого (entity) было более четко отделено от поня-

тия сообщения (message), следующим образом:

• Сообщение. Сообщение представляет собой единицу передачи данных в HTTP

и содержит заголовки и (необязательно) тело.

Глава

7.НТГР/1.1

225

• Содержимое. То, что реально передается с помощью сообщения. Содержимое

подразделяется на заголовки содержимого и тело содержимого.

В HTTP/1.1 было введено представление о кодировагши при передаче {trans-

fer-coding),

в отличие от кодирования содержания (content coding) в НТТР/1.0.

В НТТР/1.0 не было способа отличить кодирующее преобразование, применяемое

к содержимому, от преобразования, применяемого к телу содержимого. Кодирова-

ние содержания применяется ко всему содержимому, тогда как кодирование при

передаче относится к кодированию, применяемому к телу содержимого. Вид преоб-

разования указываются с помощью значения кодирования при передаче.

Документ с кодированным содержанием часто передается

о г

отправителя к полу-

чателю без каких-либо изменений на промежуточных тагах передачи. Получатель

декодирует содержание. Например, типичным примером кодировашш содержания

является сжатие; отправитель сжимает документ, а получатель восстанав./пшас]' его.

С другой стороны, кодирование при передаче преобразует тело содержимого для

того,

чтобы надежно транспортировать его по сети. Кодирование при передаче явля-

ется свойством сообщения, а не исходного содержимого. Поскольку кодирование

при передаче является свойством сообщения, оно может добавляться или удаляться

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

может применяться к сообщению, содержание которого является закодированным.

Механизму кодирования при передаче ничего не известно о семантике сообщения.

Выбор конкретного алгоритма кодирования содержания, например, алгоритма сжа-

тия,

может зависеть от конкретного тина содержания. Алгоритм кодирования при

передаче, наоборот, преобразует сообщение механически, независимо от содержания.

В терминах синтаксиса HTTP-сообщения удаление заголовков сообще1Н1я ос-

тавляет нам тело сообщения. Но если удалить заголовки сообщения и вьн10лнит1>

декодирование при передаче, то будет получено тело содержимого. В НТТР/1.0

удаление заголовков сообщения непосредственно дает тело содержимого.

На рис. 7.1 показан процесс кодирования сообщения при передаче. Заметьте,

что это кодирование не зависит от семантики содерл<ания. Содержание уже могло

быть закодировано до того, как было осуществлено кодирование для передачи.

HTTP-заголовок

Содержание

(может быть

закодировано)

Кодирование

при передаче

НТГР-заголовок

Сообщение, часть 1

Сообщение, часть 2

Сообщение, часть 3

Рис.

7.1. Кодирование сообщения при передаче

226

Часть III. Web-протоколы

На рис. 7.2 показано как сообщение, которое было закодировано при передаче,

может быть восстановлено для получения исходного сообщения. Сначала осущест-

вляется преобразование, обратное преобразованию, которое применялось для коди-

рования при передаче. Затем, если содержание кодировалось, оно декодируется

для получения исходного сообщения.

Сообщение,

закодированное

при передаче

Преобразование,

_w обратное

кодированию

при передаче

Преобразование,

-•{ обратное

кодированию

содержания

Сообщение

Рис. 7.2. Восстановление исходного сообщепия

То,

что сообщение закодировано при передаче, определяется в НТТР/1.1 с но-

моин:>ю следующих двух новых заголовков:

• Заголовок запроса ТЕ используется отправителем для указания кодирования

при передаче, которое приемлемо для него в ответах.

• Общий заголовок Transfer-Encoding, который используется для указания ко-

дирования при передаче, примененного к данному сообщению.

Сам механизм кодирования при передаче является механизмом промежуточных

передач, так как промежуточные средства могут осуществлять его декодирование и

добавлять свое собственное. И ТЕ, и Transfer-Encoding являются заголовками про-

межуточных передач. Применение ТЕ и Transfer-Encoding описано в разделах 7.4.3

и 7.12.2, соответственно.

7.2. Методы, заголовки, коды ответов в 1.0 и 1.1

в этом разделе мы перечислим отличия между НТТР/1.0 и НТТР/1.1. Отличия

разделены на три части и относятся к старым и новым методам запросов, заголов-

кам и кодам ответов. Методы, заголовки и коды ответов составляют большую часть

синтаксиса протокола. Анализ новых методов запросов, заголовков, кодов ответов

дает общее представление о масштабе отличий между НТТР/1.0 и НТТР/1.1. До-

бавление заголовков, снижение неопределенности при выборе правильного заго-

ловка и установление правил для задания нескольких заголовков

—

все это увели-

чивает и объем, и сложность протокола. Семантика этих изменений обсуждается

в следующих разделах. Таблицы служат указателями разделов, в которых обсужда-

ются семантические изменения.

7.2.1.

Старые и новые методы запросов

Как показано в таблице 7.1, в НТТР/1.0 было только три метода запросов (GET,

HEAD и POST). Остальные четыре метода (PUT, DELETE, LINK, UNLINK) ис-

пользовались только в некоторых реализациях НТТР/1.0 и описаны в приложении

к RFC 1945. Однако во многих реализациях эти методы отсутствуют. На самом

деле,

даже в тех продуктах, в которых эти методы есть, они не были реализованы

сд1Н10образно. Два из этих четырех методов (PUT и DELETE, помеченные в табли-

це 7.1 звездочкой) были сохранены и формально определены в НТТР/1.1. Другие

лна метода (LINK и UNLINK) в НТТР/1.1 отсутствуют. В НТТР/1.1 введены три

Глава 7. НТГР/1.1

227

новых метода запросов (OPTIONS, TRACE и CONNECT). Изменения в методах

НТТР/1.0 настолько значительны, что заслуживают отдельного обсуждения, кото-

рое мы оставляем до последующих разделов этой главы.

Являясь информационным, RFC 1945 не определял уровни требований к мето-

дам. Состояние требований, связанных с различными методами в НТТР/1.1, доку-

ментировано в RFC 2616.

Таблица 7.1. Методы запросов в НТТР/1,1.

Числа в третьем столбце указывают номера разделов в данной главе. С помощью '*'

помечены методы НТТР/1.0, а с помощью '|' обозначены нестандартные методы НТТР/1.0.

Метод

GET*

HEAD*

POST*

PUTt

DELETEt

OPTIONS

TRACE

CONNECT

1 ,__

Новое/изменение в HTTP/1.1

Запрос частей содержимого

Разрешены заголовки условных запросов

Управление соединением, пересылка сообщений

Метод формализован

Новый метод, расширяемость

Новый метод, для будущих применений

Раздел 1

7.4.1

7.12.1

7.5,

7.6

7.12.1

7-7

7.7

7.12.1 \

В соответствии с требованиями только методы GET и HEAD должны быть реа-

лизованы обязательно (уровень требований MUST). Иначе говоря, браузер, коррект-

но реализующий эти два метода, сможет взаимодействовать с Web-сервером (также

реализующим только эти два метода) и оба смогут претендовать на совместимость

с НТТР/1.1. Конечно, сервер должен возврап^ать корректные коды ошибок для ме-

тодов, которые в нем не реализованы. На деле в большинстве браузеров и серверов

реализовано значительно больше, чем только эти два обязательных метода.

7.2.2. Старые и новые заголовки

Заголовки — это основное средство изменения режима запроса и предоставле-

ния метаданных о ресурсе. В следующих разделах мы рассмотрим заголовки: об-

щие,

запросов, ответов, содержимого и промежуточных передач.

ОБЩИЕ ЗАГОЛОВКИ

В НТТР/1.0 определены только два общих заголовка (Date и Pragma).

В НТТР/1.1 имеются семь дополнительных общих заголовков. Общие заголовки

могух использоваться в запросах, в ответах и обычно относятся к более общим по-

нятиям, чем заголовки запросов и ответов. В таблице 7.2 перечислены общие заго-

ловки и связа1Н1ые с ними основные понятия. Мы обсудим новые общие заголовки

позже в этой главе.

Заголовки Date и Pragma, о которых шла речь в главе 6 (раздел 6.2.3), присут-

ствовали и в НТТР/1.0. Список допустимых форматов даты и времени был изме-

нен, из него были удалены ранее допустимые в RFC 1036 форматы даты.

В RFC 1036 допускалось указание года в виде строки из двух цифр, что очевидно

неприемлемо в свете проблемы двухтысячного года (для представления года требу-

ются четыре, а не две цифры). Таким образом, хотя клиенты и серверы но-нрежне-

228

Часть

III. Web-протоколы

му могут принимать данные во всех трех форматах (RFC 822/1123, RFC 850/1036

и формат asctimeO, принятый в ANSI С), генерировать они могут только строки

дат в форхмате RFC 1123.

Таблица 7.2. Общие заголовки в НТТР/1.1.

С помощью '*' помечены общие заголовки НТТР/1.0.

Заголовок

Date*

Pragma*

Cache-Control

Connection

Trailer

Transfer-Encoding

Upgrade

Via

Warning

Определение/семантическое пон51тие(ия)

Дата/время создания сообщения

Директива сообщения

Директива кэширования

Управление соединением при промежуточных передачах

Список заголовков в конце сообщения

Преобразование тела сообщения

Переход на другие протоколы

Получение информации о промежуточных серверах

Уведомление об ошибке

Раздел 1

6.2.3

7.3.3

7.1.3,

7.5

7.6

7.7

7.12.2

В семантику общего заголовка Pragma ие внесено никаких изменений, к нему

не добавлено никаких новых директив. Протоколом не выдвигается требований

к использованию директивы Pragma. В НТТР/1.0 Pragma: no-cache определено

только для сообщений-запросов, в НТТР/1.1 действие директивы не расширено на

сообщения-ответы. НТТР/1.1 разрешает использование Pragma для обеспечения

обратной совместимости и вводит более общий механизм управления кэшами по-

средством общего заголовка Cache-Control. Заголовок Cache-Control использует-

ся,

чтобы передавать директивы в запросах и ответах, а также управлять поведени-

ем компонентов кэша.

ЗАГОЛОВКИ ЗАПРОСОВ

Как видно из таблицы 7.3, в НТТР/1.0 было 5 заголовков запросов, а в НТТР/1.1

их 19. Все 5 заголовков запросов из НТТР/1.0 (Authorization, From, If-Modi-

fied-Since, Referer и User-Agent) оставлены в НТТР/1.1, хотя семантика некоторых

из них изменена. В частности, возможности аутентификации доступа, описываемые

заголовком Authorization, в НТТР/1.1 значительно расширены. Существует отдель-

ный RFC, в котором описаны обычная (Basic) аутентификация и аутентификация

с помощью дайджестов [FHBH^99j. В НТТР/1.0 модификатор запроса If-Modi-

fied-Since можно было использовать только с методом GET, а в НТТР/1.1 его мож-

но использовать с любым методом.

Мы подразделяем заголовки запросов па четыре класса, следующим образом:

• Предпочтения в ответе. Заголовки, используемые для передачи дополнитель-

ной информации о предпочтениях в ответах, например, о языке или наборе

символов.

• Информация, передаваемая вместе с запросом. Заголовки, используемые

для передачи в сообщении дополнительной информации, например, информа-

ции идентифицирующей пользователя и/или браузер.

Глава 7. HTTP/1.1

229

• Условные запросы. Заголовки, используемые для услов1н>]х запросов, кото-

рые меняют интерпретацию сервером да1Н10]ю метода запроса.

• Ограничения, накладываемые на сервер. Заголовки, используемые zuni полу-

чения определенной реакции сервера.

14 новых заголовков запросов в НТТР/1.1 обсуждаются в соответствующих

разделах позже в дайной главе.

Таблица 7.3. Заголовки запросов НТТР/1.1.

Числа в последнем столбце указывают помер раздела в данной или в предыдущей

главах. С помощью '*' помечены заголовки запросов ИТГР/1.0.

Класс

Предпочтения

в ответе

Информация,

передаваемая

вместе

с запросом

Условный

запрос

Ограничения,

накладываемые

па сервер

Заголовок

Accept-Charset

Accept-Encoding

Accept-Language

ТЕ

Authorization*

From*

Referer*

User-Agent*

Proxy-Authorization

If-Modified-Since *

If-Match

If-None-Match

If-Unmodified-Since

If-Range

Expect

Host

Max-Forwards

Range

Краткое описание (Раздел) |

Предпочтительные типы содсржагнш (7.9)

Предпочтительные наборы символов (7.9)

Предпочтительные схемы кодирования i

содержания (7.9)

Предпочтительные языки (7.9)

Предпочтительные схемы кодирования при |

передаче (7.4.3) |

Полномочия агента пользователя (6.2.3)

Адрес электронной почты по./н^зовате.'1я (6.2.3)

URI, от которого получен URI запроса (6.2.3)

Информация 0 програмлпюм обеспечении агента j

пользователя (6.2.3) |

Авторизация клиента прокси-сервером (7.11.3) |

Сравнение с временем иоследиего измепепия (6.2.3)

Сравпенпе атрибутов содержимого (7.3.3)

Сравнение атрибутов содержимого (7.3.3)

Сравнение с временем последнего нзмепс1гия (7.4.1)

Отправить диапазон, только если содержимое пс

измепеио (7.4.1) |

Реакция сервера, ожидаемая

КЛИСЕГГОМ

(7.4.2)

Хост запрошенного ресурса (7.8)

Допустимое число переходов при передаче данных j

(7.7.1)

Запрос диапазона содержимого (7.4.1)

ЗАГОЛОВКИ ОТВЕТОВ

Заголовки ответов используются для предоставления дополнительной информа-

ции о сервере или о самом ответе. Заголовки ответов были изменены в НТТР/1.1

двумя способами: существующие в НТТР/1.0 заголовки ответо1з (Location, Server и

WWW-Authenticate) были уточнены, кроме того, были добав./1ены шесть новых за-

головков ответов. Проведено различие между заголовком ответов Location и новым

заголовком содержимого Content-Location.