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

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

190

Часть

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

Введение терминологии MIME затруднило разделение ролей нолей заголовка,

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

ру или наоборот. Набор нолей HTTP-заголовка стал трактоваться, как произволь-

ный набор строк ASCII, который может игнорироваться Web-комнонентами, если

последние их не понимают. HTTP-заголовки, как мы увидим в разделе 6.2.3 и

в главе 7 (раздел 7.2.2), используются как для предоставления метаданных, так и

для модификации поведе1Н4я и интерпретации методов HTTP.

HTTP и ПРОТОКОЛЫ ARCHIE, GOPHER И WAIS

На разработку HTTP оказали влияние протоколы, которые были популярны во

время создания Web. В главе 1 (раздел

1.1.1)

обсуждалась роль, которую сыграли

системы Archie, Gopher и WAIS в эволюции Web в целом. Различные аспекты, от-

носящиеся к протоколам таких систем, повлияли на принципы, положенные в ос-

нову HTTP. В частности, в Gopher [AML^93] имелся протокол клиент-сервер, не

сохраняющий состояние и схожий с тем, который был реализован в HTTP. Все

серверы используют фиксированные ТСР-норты: 70 в Gopher, 210 в WAIS и 80

в HTTP. Идея типа документа в зачаточном состоянии использовалась в Gopher. В

HTTP понятие типа содержания было значительно расширено.

Протокол Prospero [NA93J, который создал условия для единообразного обра-

щения к множеству файлов в Internet, был применен в Archie. Prospero отличался

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

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

расположенных в любой точке Internet. Prospero был достаточно простым в смысле

разделения доступа к да1Н1ЫМ и интерпретации да1Н1ых. Однако он не имел специ-

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

другие протоколы, такие как FTP и Gopher. Сам Prospero использовал протокол

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

гюверх UDP. В противоположность этому, HTTP, Gopher и WAIS обычно исполь-

зуют TCP. В Prospero, в отличие от Gopher, не предусмотрены различные уровни

аутентификации. В последних версиях Archie'планировалось использовать URI.

Главным назначением протокола Gopher было удаленная выборка документов.

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

в HTTP, в Gopher использовались текстовые файлы и меню. HTTP трактует меню

и текстовые файлы как особый вид гипертекста [BL92a]. Было бы неправильно

сравнивать Gopher с более поздними версиями HTTP, поскольку протокол Gopher

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

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

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

Gopher отсутствовал какой-либо механизм для идентификации несоответствий ме-

жду кэшированными элементами и текущим содержанием. Кэширование выполня-

лось на уровне приложений, вне протокола Gopher. Протокол Gopher был специ-

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

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

широкого набора сервисов требовало усовершенствования сервера без внесения из-

менений в протокол. Хотя при этом протокол является гораздо более нростььм, чем

HTTP, различные реализации серверов могут вести себя по-разному. Gopher опре-

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

ется доступ, текстовым файлом, каталогом, двоичным файлом и т.д. Выбор одного

символа для идентификации тина ресурса естественно ограничивает количество

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

Глава

Структура

описание протокола HTTP

191^

к расширенному набору МШЕ-типов, а различные программные компоненты

HTTP получили возможность воспринимать произвольные типы ресурсов. В про-

токоле Gopher не затрагиваются вопросы безопасности.

HTTP и ДРУГИЕ ПРОТОКОЛЫ ПРИКЛАДНОГО УРОВНЯ

На HTTP оказали влияние другие протоколы прикладного уровня, которые

предшествовали Archie, Gopher и WAIS. Сам HTTP тоже повлиял па протоколы

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

взаимовлияний.

HTTP перенял идею классов ответов (раздел 6.2.4) от протокола прикладного

уровня SMTP [Pos82]. Вместо того чтобы попытаться изобрести новую схему для

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

функциональной

группы кодов ответов SMTP. Функциональная группа классифицировала ответы

на небольшое число категорий, таких как успех, неудача или ошибка. По мере раз-

вития HTTP список классов расширялся, но базовая схема осталась неизменной.

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

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

уровня, которые переняли синтаксис и часть семантики HTTP, например. Real Time

Streaming Protocol (RTSP) [SRL98], о котором пойдет речь в главе 12 (раздел 12.4).

6.2. Элементы протокола HTTP

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

цификация НТТР/1.0 (RFC 1945) была гораздо более подробной, нежели специфи-

кация НТТР/0.9. Спецификация включает раздел, подробно описывающий терми-

нологию, грамматику, а также компоненты HTTP-сообщений. Сначала мы познако-

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

протокола, а затем обсудим различные элементы. Как упоминалось ранее, прото-

кол

—

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

ловки и классы ответов.

6.2.1 Термины, относящиеся к HTTP

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

жатся в двух документах RFC, описывающих НТТР/1.0 и НТТР/1.1 (соответст-

венно RFC 1945 [BLFF96J и RFC 2616 [FGM'^99J). Где это необходимо, мы предос-

тавим дополнительные пояснения и примеры. Большинство терминов было опре-

делено в главе 1. Здесь мы более подробно остановимся на четырех важных

понятиях: сообщение, содержимое, ресурс и агент пользователя,

СООБЩЕНИЕ

HTTP-сообщение представляет собой последовательность байтов, передаваемых

но соединению транспортного уровня. Сообщение

—

это основная единица комму-

никационного взаимодействия в HTTP. НТТР-сообщеиие может быть запросом,

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

Сообщение-запрос начинается со строки

запроса,

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

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

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

волами: возврата каретки (CR) и перевода строки (LF).

192

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

Сообщение-запрос HTTP, показанное на рис. 6.1, имеет следующий синтаксис:

Строка запроса

Заголовок (заголовки) общий/запроса/содержимого

CRLF

Необязательное тело сообщения

Сообщение-запрос начинается со строки запроса, за которой следует ряд необяза-

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

тод запроса, запрашиваемый URI и версию протокола клиента. Например, в HTTP-

запросе

GET /motd НТГР/1.О

Date:

Wed, 22 Mar 2000 08:09:01 GMT

Pragma: No-cache

From:

gorby@mo8kvax.com

User-Agent: Mozilla/4.03

CRLF

также представленным на рис. 6.1, методом запроса является GET, запрашивается

ресурс /motd, а клиентской версией протокола является НТТР/1.0. Заголовки Date,

Pragma являются общими заголовками, такие заголовки могут присутствовать в за-

просах и ответах. Заголовки From и User-Agent являются заголовками запроса и

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

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

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

лов возврата каретки и перевода строки. В этом HTTP-сообщении пет информаци-

онного содержания (тела содержимого).

GET /motd HTTP/1.0

Date:

Wed, 22 Mar 2000 08:09:01 GMT

Pragma: No-cache

From:

gorby@moskvax.com

User-Agent: Mozifia/4.03

<Тело запроса отсутствует>

Строка

запроса

Общие заголовки

Заголовки

запроса

Рис.

6.1. Сообщение-запрос HTTP

На рис. 6.2 показано сообщение-запрос с телом сообщения. Для создания ресур-

са /motd используется метод PUT. За методом запроса следует один общий заголо-

вок (Date) и два заголовка запроса (From и User-Agent). Сообщение-запрос имеет

два заголовка содержимого (Content-Length и Allow). Первый из них указывает

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

сурсу /motd. Тело содержимого состоит из строки Welcome to Comer's Vox.

Глава 6. Структура и описание протокола HTTP

193

PUT /motd HTTP/1.0

Date:

Wed, 22 Mar 2000 08:10:07 GMT

From:

gorby@moskvax.conn

User-Agent: Mozilla/4.03

Content-Length: 23

Allow: GET, HEAD, PUT

Welcome to Comer's Vax

Строка

запроса

Общие заголовки

Заголовки запроса

Заголовки

содержимого

Тело содержимого

Рис. 6.2. Другое сообщение-запрос HTTP

Сообщение-ответ имеет следующий синтаксис:

Строка состояния

Заголовок (заголовки) общий/ответа/содержимого

CRLF

Необязательное тело сообщения

Сообщение-ответ начинается со строки состояния, которая содержит номер вер-

сии HTTP сервера и код ответа. Далее следуют необязательный общи11 заголовок,

заголовок ответа, а также необязательное тело сообщения. Следует замст1ггь, что

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

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

показано сообщение-ответ для описанного выше запроса GET.

НТТР/1.0 200 ОК

Date:

Wed, 22 Mar 2000 08:09:03 GMT

Server: Netscape-Enterprise/3.5.1

Content-Length: 23

Welcome to Comer's Vax

Строка

запроса

Общие заголовки

Заголовки запроса

Заголовки

содержимого

Тело содержимого

Рис. 6.3. Сообщение-ответ HTTP

194

Часть

III.

Web-протоколы

HTTP/1.0 200

Date:

Wed,

22 Mar

2000 08:09:03

GMT

Server: Netscape-Enterprise/3.5.1

Content-Length:

CRLF

Welcome to Comer's Vex

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

НТТР/1.0, а код ответа 200 ОК указывает на успешное выполнение запроса. Сооб-

щение-ответ содержит общий заголовок Date и заголовок ответа Server. Заголовок

содержимого Content-Length отражает длину тела содержимого. За последователь-

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

бой строку

Welcome

Comer's

Vox.

Сообщение не имеет тела содержимого, если отсутствует тело сообщения. Тело

сообщения в запросе и ответе также называют

телом

запроса и телом

ответа,

со-

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

СОДЕРЖИМОЕ

НТТР/1.0 определяет содержимое как представление ресурса, которое заключе-

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

мого и необязательного тела содержимого. Заголовки содержимого состоят из ме-

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

Content-Length. Очевидно, что ответ, у которого значение Content-Length равно

нулю,

не будет иметь тела содержимого. Определение содержимого несколько от-

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

ханизма согласования содержимого (описанного в главе 7, разделе 7.9).

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

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

быть данные, введенные пользователем в HTML-форму. В сообщении-ответе телом

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

РЕСУРС

НТТР/1.0 [BLFF96] определяет ресурс как «сетевой объект данных или сервис,

который может быть идентифицирован унифицированным идентификатором ресур-

са (URI)». Термин «сетевой» означает, что объект данных или сервис могут распола-

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

ние.

Решение расширить определение ресурса сервисом имело важное значение.

Объект данных может быть статическим или генерироваться динамически, тогда как

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

Web в качестве транспортгюго средства для инициирования сервиса и предоставле-

ния ответа. Например, рассмотрим Web-сайт, который возвращает текущие котиров-

ки акций. Цены на акции постоянно меняются, и ресурс http://www.cnnfh.com/

quote=T? будет выдавать текущую цену акций AT&T. Сервис предоставления коти-

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

цены акций. Он просто использует Web как механизм для передачи запроса (опре-

деленного набора акций) и ответа (текущей цены каждой из акций).

АГЕНТ ПОЛЬЗОВАТЕЛЯ

Агент пользователя

—

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

браузером, спайдером или любым другим средством, участвующим в формирова-

Глава 6. Структура и описание протокола HTTP 195

НИИ запроса. Разница между агентом пользователя и клиентом очень важна. Обыч-

но к инициирующему компоненту предъявляются дополнительные требования.

Агент пользователя является единственной стороной, непосредственно связываю-

щейся с пользователем, если запрос был инициирован пользователем. Агент поль-

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

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

тификации, переадресовать запрос или указать определенное альтернативное место

назначения, либо изменить представление ответа. Например, агент пользователя

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

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

тем запросить у пользователя соответствующие данные и повторно отправить за-

прос,

содержащий аутентификационную информацию.

Часто информация об агенте пользователя гюсылается как часть запроса в заго-

ловке User-Agent (описанном более подробно в разделе 6.2.3). Заголовок содержит

такую информацию, как названия браузера и операционной системы компьютера.

В качестве примера приведем: Mozilla/3.01 (XII; I; SunOS 5.5 sun4m) и Mozilla/2.0

(compatible; MSIE 2.1; AOL 3.0; Mac). Имеется возможность идентифицировать

версию браузера (Mozilla/3.01 или MSIE 2.1) и операционной системы, применяе-

мой пользователем (например, SunOS 5.5).

6.2.2. Методы запроса НТТР/1.0

Метод запроса уведомляет HTTP-сервер, какое действие следует выполнить над

ресурсом, идентифицируемым URI запроса (т.е. URI, указываемом в строке запро-

са).

Наиболее часто используется метод GET, который осуществляет выборку теку-

щего содержимого ресурса, идентифицируемого URI. Хотя в НТТР/1.0 определены

только три метода (GET, HEAD, POST), в некоторых версиях клиентов и серверов,

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

DELETE, LINK и UNLINK. Все семь методов уже применялись в различных реали-

зациях на момент появления спецификации НТТР/1.0. Поскольку методы LINK и

UNLINK не входят в стандарт HTTP/1.1, они не будут подробно рассматриваться.

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

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

к необходимости обращения к двум другим. На данный момент достаточно будет

знать, из каких элементов состоит транзакция запрос-ответ:

• Метод запроса включается в клиентский запрос вместе с несколькими заго-

ловками и URI.

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

ответ. Ответ состоит из кода ответа, метаданных о ресурсе и других заголов-

ков ответа.

Имейте в виду, что промежуточное звено, такое как кэширующий прокси-сервер,

получающий запрос и возвращающий кэшированный ответ, не применяет метод.

Двумя важнейшими характеристиками метода являются безопасность и идем-

потентность. Метод запроса, который лишь просматривает состояние ресурса (на-

пример, получает текущее содержимое), считается безопасным методом. Метод, ко-

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

пый метод, с другой стороны, имеет то свойство, что побочные эффекты для

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

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

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

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

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

тода па ресурс является полезной для определения, должен ли ресурс поддержи-

вать метод. Кроме того, если последовательность запросов идемпотентпа, и если

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

набор запросов.

Ниже описываются методы НТТР/1.0.

GET

Наиболее популярным на сегодняшний день является метод GET. Запрос GET

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

пдее значение ресурса. Этот ответ возвращается обратившемуся с запросом клиен-

ту. Если URI указывает па статический файл, запрос GET обычно приводит к чте-

нию файла и возврату его содержимого. Если URI указывает на программу, то

в теле ответа возвращаются данные (если они имеются). Метод GET является

безопасным и идемпотентным. Запрос па CGI-pecypc, например, может вызвать из-

менение ресурса при применении к нему метода GET. Поскольку такой побочный

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

Запрос GET может содержать параметры, которые формируются па основе дан-

пых, введенных пользователем. Это часто имеет место при запросе CGI-pecypca.

Например,

GET http://www.altavista.com/cgi-bin/query?q=foo

передает пользовательскую строку запроса ("foo") ресурсу http://www.altavista.com/

cgi-bin.

Запрос GET, содержащий модификатор запроса, может привести к выполнению

дру1'ого действия. Например, методу GET может быть предписано выбирать ресурс

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

больше, чем значение, указа]П1ое в заголовке If-Modified-Since. Таким образом, за-

прос GET па ресурс /foo.html от клиента НТТР/1.0

GET /foo.html НТТР/1.0

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

GET /foo.html НТТР/1.0

If-Modified-Since: Sun, 12 Nov 2000 11:12:23 GMT

в зависимости от того, когда ресурс /foo.html был в последний раз модифицирован

па исходным сервере. Модификатор запроса If-Modified-Since используется для

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

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

дифицирован с момента времени, указанного в заголовке If-Modified-Since, сервер

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

мого.

Отметим, что знание времени последней модификации упрощает работу с пе-

риодпческп изменяемыми файловыми ресурсами. Для динамически генерируемого

ресурса знание времени последней модификации особого значения не имеет.

В НТТР/1.0 имеется несколько полезных модификаторов запроса. В НТТР/1.1 был

добавлен еще ряд модификаторов, как мы увидим в следующей главе.

Метод запроса GET не имеет тела запроса. Если тело запроса присутствует, сер-

верами оно игнорируется.

Глава 6. Структура и описание протокола HTTP 197

HEAD

Метод HEAD был задуман для получения метаданных, ассоциированн1ях с ре-

сурсом. В результате выполнения запроса HEAD тело отвега не возвращается. Од-

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

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

прос HEAD для получения метаданных, ассоциированных с ресурсом /foo.html,

HEAD /foo.html HTTP/1.0

может вернуть

НТТР/1.0 200

ОК

Content-Length:

3219

Last-Modified: Sun,

12 Nov

2000 11:12:23

GMT

Content-Type: text/html

Ответ состоит из строки состояния (НТТР/1.0 200 ОК), указыва]0И1ей на yciieni-

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

ресурса /foo.html. В этом примере метадаппые содержат информацию о длине со-

держимого, времени последней модификации ресурса и тине ресурса. Метод

HEAD безопасен и идемпотентен.

Метод HEAD в основном используется при отладке для серверов с oiмоситель-

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

мента последней его загрузки. Метаданные могут кэин4роват1)Ся или использовать-

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

менение ресурса. В НТТР/1.0 изменение может быть обнаружено путем анализа

значений нолей заголовков Last-Modified или Content-Length. Однако в связи

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

только поля заголовка Content-Length не гарантирует обнаружения изменен и

li.

В НТТР/1.0 метод HEAD нельзя использовать с модификаторами запроса, та-

кими как If-Modified-Since. Это ограничение было снято в НТТР/1.1.

Метод запроса HEAD также не имеет тела запроса. Если тело запроса присутс г-

вует, серверами оно игнорируется.

POST

в отличие от методов GET и HEAD, которые используются для извлечения пи-

формации, метод POST применяется главным образом для модпфнкащн! имеюще-

гося ресурса или передачи данных обрабатывающему их процессу. Тело запроса со-

держит данные. Исходный сервер в зависимости от URI запроса, разрешает выпол-

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

поэтому пе может считаться безопасным методом. Поскольку нобоч1н>1е эффекты

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

потептным методом.

Чтобы модифицировать ресурс, пользователь должен иметь необходимые пол-

номочия. Не все пользователи могут обладать правами на изменение ресурса. Если

пользователь имеет право на изменение ресурса, исходный сервер примет новую

версию ресурса от клиента. Другое нрименение метода POST состоит в получении

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

граммы, идентифицируемой URI запроса. Такой программой может бьп ь почтовая

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

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

Бывает также, что в результате вьн10лне1Н1Я запроса POST ресурсы не изменяются

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

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

программы, которая использует эти данные.

Рассмотрим пример:

POST /foo/bar.cfm HTTP/1.0

Content-Length:

143

<тело содержимого>

Если принимающий сервер может успешно применить метод к ресурсу, он воз-

вращает ответ, указывающий на успешное выполнение запроса. Предположим, что

/foo/bar.clm представляет собой ресурс, который не существует на исходном сер-

вере.

Сервер создаст ресурс и отправит ответ, указывающий на то, что ресурс был

создан. Если, с другой стороны, /foo/bar.cfm является программой, ожидающей

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

для программы. Любой выход, генерируемый программой, отправляется обратно

пользователю как тело ответа. Следует иметь в виду, что заголовок Content-Length

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

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

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

грамме. Однако в использовании для этих целей методов GET и POST имеются

различия. В запросе GET входные данные включаются в URI запроса. Предполо-

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

база да1Н1ых, в которой следует вести поиск. Например, запрос

GET /search.cgi?string=iktinos&db=greek-architects HTTP/1.0

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

ны в URI запроса. Здесь запрашиваемым с помощью метода GET ресурсом являет-

ся search.cgi, которому передаются значения двух полей (string и db). При исполь-

зовании метода POST этот же запрос выглядел бы следующим образом:

POST /search.cgi HTTP/1.0

Content-Length: 34

CRLF

query iktinos

db greek-architects

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

между клиентом и исходным сервером имеются посредники. Посредник обычно

регистрирует проходящие через него запросы. Но в то время как URI запроса ско-

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

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

сена в журнал, а в случае запроса POST

—

нет. Некоторые посредники и серверы

ограничивают длину подлежащего обработке URI, и это может стать еще одной

причиной, чтобы предпочесть метод POST методу GET при передаче данных форм.

PUT

Метод PUT схож с методом POST в том, что выполнение метода обычно приво-

дит к изменению ресурса, идентифицируемого URI запроса. Если запрашиваемый

через URI ресурс не существует, он создается, а если ресурс существует, то моди-

фицируется. При использовании метода PUT в результате выполнения запроса из-

меняется сам идентифицируемый URI ресурс.

Глава

Структура

описание протокола HTTP

199

В НТТР/1.0 метод PUT официально не определен. На момент выхода RFC 1945

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

этому метод PUT (наряду с методами DELETE, LINK, UNLINK) был вкратце упо-

мянут в приложении RFC 1945. В главе 7 (раздел 7.12.1) мы подробнее поговорим о

различиях между методами PUT и POST. Метод PUT не является безопасным ме-

тодом. Метод PUT является идемнотентным, поскольку последовательность иден-

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

бочные эффекты каждый раз будут одинаковыми.

DELETE

Метод DELETE используется для удаления ресурса, идентифицируемого URI

запроса. Метод предоставляет возможность дистанционного удаления ресурсов.

Однако принимая во внимание суть этого действия, исходные серверы контроли-

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

произошло. Сервер может отправить ответ об успешном выполнении, в действи-

тельности не удалив ресурса. Имеется два вида ответов для успешного выполне-

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

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

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

также чтобы не приходилось держать открытым соединение с клиентом до тех нор,

пока действие реально не будет завершено. Метод DELETE не является безопас-

ным методом. Подобно методу PUT, метод DELETE

является

идемнотентным.

LINK И UNLINK

Метод LINK позволяет создавать связи между запрашиваемым URI и другими

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

ному и тому же URI запроса. Метод UNLINK используется для удаления связей,

созданных посредством метода LINK.

Хотя эти методы были определены в приложении НТТР/1.0, они не получили

широкого распространения и в НТТР/1.1 отсутствуют.

6.2.3.

Заголовки НТТР/1.0

Заголовок (или, точнее говоря, поле заголовка)

—

это ASCII-строка в свобод-

ном формате, в котором задано имя, а часто и значение. Заголовки играют важную

роль в протоколе HTTP и

являются

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

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

о ресурсе, таких как его длина, формат кодирования и язык. Заголовки можно счи-

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

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

чения исходного содержания (например, какой алгоритм сжатия был применен для

его преобразования).

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

ловки. В противоположность фиксированному формату заголовков IP и TCP, про-

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

ловков. В протоколах нижних уровней размер пакетов часто ограничивается из со-

ображений производительности. Фиксированный формат заголовков протоколов

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

в результате добавления заголовков. Для протоколов прикладного уровня такой

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

бом добавления новых функций.