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

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

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

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

вольную длину. Механизм расширяемости протокола (вкратце об этом речь пойдет

в разделе 6.3) дает возможность отражать новые идеи в виде новых заголовков. Не-

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

—

игно-

рировать нераспознанные заголовки. Однако неограниченный рост числа полей за-

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

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

загрузки сети. Большое число новых заголовков может также увеличить сложность

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

головков, — существенный фактор в увеличении сложности.

НТТР-сообщепие может иметь любое число заголовков, отделяемых символами

CR и LF. Существуют определенные правила, связанные с передачей и интерпрета-

цией заголовков сообщения по мере прохождения запроса или ответа в сети через

серверы-посредники. Определенные типы сообщений запросов-ответов HTTP могут

иметь обязательные заголовки. Большинство заголовков ие являются обязательны-

ми,

и Web-KOMHoneiribi добавляют их по определегшым причинам. Web-KOMnoiienTbi

1\югут

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

Заголовки, описанные в спецификации, должны быть попятными для всех Web-

компонептов: клиентов, серверов-посредников и исходных серверов.

Заголовок имеет общий синтаксис, в соответствии с которым имя и значение

отделяются друг от друга символом двоеточия ":". Например, чтобы указать время

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

следующим образом:

Date:

Thu. 23 Dec 1999 08:12:31 GMT

"Date"

представляет собой поле имени заголовка, а строка "Thu, 23 Dec 1999 08:12:31

GMT" — ноле значения. Вот пример заголовка с несколькими полями значений:

Accept-Language: de-CH, en-US

Здесь ноле имени

—

Accept-Language, а поля значений

—

de-CH и en-US.

В HTTP имеется иерархия заголовков. Заголовок сообщения в НТТР/1.0 явля-

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

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

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

предпочтительного варианта ответа, для включения дополнительной инфор-

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

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

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

1Н1формации от пользователя.

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

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

держимом, например, время последнего изменения. Если поле общего заго-

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

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

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

ся.

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

головок.

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

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

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

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

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

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

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

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

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

головков: Date и Pragma. Общие заголовки значимы только для самого сообще-

ния, но не для содержимого, являющегося частью сооби^ения. Так, нредноложнм,

что запрашивается ресурс /foo.html. Заголовок Date в соответствующем сообще-

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

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

вующее содержимое.

• Date. Общий заголовок Date указывает на дату и время создания сообщения.

Заголовок Date имеет такой же синтаксис, что и строка дачы/времени в стан-

дарте для текстовых сообщений Internet (документ RFC 822, позднее обнов-

ленный документом RFC 1123). Дата в этом формате имеет следующий вид:

Date:

Tue 16 May

2000 11:29:32

GMT

Хотя это наиболее предпочтительный формат, НТТР/1.0 разрешает исполь-

зование двух других форматов (определенном в докуме1гге RFC 1036 н

в формате asctimeQ стандарта ANSI С). Формат RFC 1036 выглядит следую-

щим образом:

Date: Tuesday, 16-Мау-ОО 11:29:32

GMT

Формату RFC 1036 присуща проблема, связанная с представлением года дву-

мя цифрами. Как видно из примера, значение года трактуется как 00 вмес-

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

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

протокола (НТТР/1.1) в результате усилий по решению проблемы двухты-

сячного года. В соответствии с форматом asctime() стандарта ANSI С дата

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

Date:

Tue May 16

11:29:32 2000

НТТР/1.0 требует, чтобы клиенты и серверы генерировали строку данных

либо в первом, либо во втором формате. Однако клиенты п серверы HTTP

могут воспринимать все три формата, что необходимо но той причине, что

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

спецификации HTTP. Спецификация протокола устанав;н1васт правила для

взаимодействия Web-компопентов друг с другом. Однако поскольку компо-

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

определен интерфейс компонентов с ними.

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

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

—

это способ указать для компонентов определенный

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

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

ректив, которым подчиняются большинство комгюнентов. Эта раз1Н1ца очень

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

вы,

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

ми.

Единственной директивой, определехнюй в протоколе, является

Pragma: no-cache

202

Часть

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

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

ния не возвращать кэшированную копию; т.е. отправитель заинтересован

в получении ответа непосредственно от исходного сервера. HTTP/1.0 не оп-

ределяет назначение директивы Pragma: no-cache в сообщении-ответе.

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

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

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

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

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

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

ным сервером. В HTTP/1.0 определены пять заголовков запроса:

• Authorization. Заголовок Authorization используется агентом пользователя

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

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

чии соответствующих полномочий. Вот пример заголовка Authorization:

Authorization: Basic YXZpYXRpS29IDizM1NA==

Здесь Basic (обычная) обозначает схему аутентификации, согласно которой

данные представляются в виде идентификатора пользователя и пароля. Строка

YXZpYXRpS29IDizMlNA== представляет собой кодированные идентифика-

тор пользователя и пароль в формате Base64 [FB96aJ. Формат использует про-

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

много длиннее исходных данных. Другие допустимые в HTTP схемы аутенти-

фикации предусматривают шифрование па транспортном уровне.

• From. Заголовок запроса From дает возможность 1юльзователю включать

в свои идентификационные данные адрес электронной почты. Это полезно

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

робот в спайдере), для идентификации пользователя, в интересах которого

функционирует программа. Вот пример заголовка From:

From:

gorby@moskvax.com

Следует заметить, что использование заголовка From нежелательно, посколь-

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

ся без его ведома.

• If-Modified-Since. Заголовок If-Modified-Since является примером условного

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

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

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

заданное в заголовке ответа Last-Modified, используется в последующем за-

просе GET в качестве аргумента в заголовке If-Modified-Since. Например, для

следующего запроса:

GET /foo.html НТТР/1.0

If-Modified-Since: Sun. 21 May 2000 07:00:25 GMT

сервер будет сравнивать значение, заданное в заголовке If-Modified-Since,

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

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

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

чено с помощью системного вызова операционной системы (например, statQ

Глава

Структура

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

203

wjiw/statQ в UNIX). Если ресурс не изменился с указанного времени Sun, 21

May 2000 07:00:25 GMT, сервер просто вернет ответ 304 Not Modified. Для

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

ных. Серверу не нужно повторно генерировать ресурс, и время ожидания на

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

мое локально.

• Referer. Поле заголовка Referer^ дает возможность клиенту включать URI ре-

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

жим, что пользователь посещает Web-страницу http://www.cnn.com и щелка-

ет на гиперссылке на ресурс http://www.disasterrelief.org/Disasters/world-

glance.html на этой странице. Заголовок Referer в запросе, передаваемом на

http://www.disasterrelief.org, будет содержать строку http://www.cnn.com:

GET /Disasters/worldglance.html HTTP/1.0

Referer: http://www.cnn.com

Польза от применения поля Referer состоит в выявлении устаревших гипер-

ссылок. Однако чаще всего оно становится источником нарушения конфи-

денциальности пользователя. Ранее (глава 2, раздел 2.6.4 и глава 3, раз-

дел 3.7) мы говорили о проблемах нарушения конфиденциальности, связан-

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

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

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

Есть и худшие ситуации. Предположим, что с помощью формы, исполь-

зующей метод GET (см. раздел 6.2.2) передается номер кредитной карты

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

(скажем, с применением SSL), а полученная после выполнения запроса

с формой страница содержит ссылку на другую страницу, возможно, находя-

щуюся на сервере S. Теперь, если пользователь переходит к этой странице,

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

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

Кроме того, сервер может осуществлять проверку поля Referer с целью

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

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

жим, что ссылка на встроенгюе изображение onlymine.gif, изначально при-

надлежащее ресурсу А, было скопировано в другой документ, В. Теперь, если

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

на ресурс onlymine.gif и включить в запрос заголовок Referer с нолем значе-

ния, соответствующим ресурсу В. Сервер может отказать в обработке запро-

са, поскольку поле Referer не содержит А.

• User-Agent. Поле User-Agent может быть использовано для включения ин-

формации о версии программного обеспечения браузера, версии операцион-

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

ратной конфигурации. Вот примеры заголовков User-Agent:

User-Agent: Mozilla/4.03 (Macintosh; I; 68K, Nav)

User-Agent: Mozilla/4.04 [en] C-WorldNet (Win95: I)

К ряду забавных моментов, связанных с HTTP, можно отнести орфографические ошиб-

ки,

например Referer вместо

Referrer,

с которыми приходится мириться, поскольку они

уже получили широкое распространение.

204

Часть

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

Эта информация достаточно полезна. Например, по ней можно получить ста-

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

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

го браузера не сможет отобразить версию, используемую но умолчанию. Со-

мшггелыюсть использования этого заголовка состоит в отслеживании дейст-

BiHi пользователя и потенциальном вторжении в его частную жизнь. Напри-

мер,

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

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

сы на ИСХ0Д1НЛЙ сервер. В этом случае поле User-Agent может быть использо-

вано для выявления пользователя, пославшего определенные запросы.

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

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

мац1Н1 о запросах, заголовки ответа применяются для отправки дополнительной ин-

формации об ответе и о сервере, создавшем ответ. Синтаксис строки состояния в заго-

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

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

В НТТР/1.0 определены три заголовка ответа:

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

расположения ресурса и полезен при переадресации ответов (см. раздел 6.2.4).

Заголовок Location имеет следующий синтаксис:

Location:

http://www.fоо.com/level1/twosdown/Location. html

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

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

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

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

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

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

сурс,

заголовок Location идентифицирует созданный ресурс.

• Server. Заголовок ответа Server аналогичен заголовку запроса User-Agent.

Заголовок Server несет информацию о версии программного обеспечения ис-

ходного сервера и любую другую информацию, связанную с его конфигураци-

ей.

Вот несколько типичных примеров заголовка Server:

Server: Apache/1.2.6 Red Hat

Server: Netscape-Enterprise/3.5.1

Server: Apache/1.x.у mod_perl mod_ssl mod_foo mod_bar

Значение, указанное в заголовке Server, полезно для выявления и решения

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

щей определить на[1более популярные версии серверов. Минусом здесь явля-

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

ку User-Agent, заголовок Server не является обязательным и может не вклю-

чаться в ответы.

• WWW-Authenticate. Заголовок WWW-Authenticate используется для ука-

зания клиенту, что ресурс требует аутентификации. Клиенту возвращается от-

вет 401 Unauthorized, и он может повторно обратиться с запросом, указав со-

ответствующие данные в заголовке Authorization. Например, сервер может от-

править такой ответ:

Глава 6. Структура и описание протокола НТГР 205

www-Authenticate: Basic realm="ChaseChem"

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

ную информацию, как разъяснялось ранее в этом разделе.

ЗАГОЛОВКИ СОДЕРЖИМОГО

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

жимого или о ресурсе при отсутствии тела содержимого. Заголовок содержимого

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

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

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

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

кол задает иерархию для интерпретации полей заголовка. В сообщение запроса

или ответа может быть включен новый заголовок, добавляющий новые метаданные

о содержимом без опасения, что он будет интерпретирован как общ1Н4 заголовок,

заголовок ответа или заголовок запроса.

В НТТР/1.0 определено шесть заголовков содержимого:

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

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

зоваться и в запросах, и в ответах. Например, метод PUT может содержать за-

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

к ресурсу. При получении запроса па применение некорректного метода к ре-

сурсу исходный сервер отправит в ответ заголовок Allow со списком допусти-

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

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

сурса методов.

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

просе

PUT /foo.html НТТР/1.0

Allow: HEAD, GET,

PUT

Запрос информирует сервер, где будет сохранен ресурс /foo.html, что к этому

ресурсу разрешается применять методы HEAD, GET и PUT. Другие ^методы

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

каться исходным сервером.

• Content-Type. Заголовок Content-Type указывает на тин представления тела

содержимого, например,

image/gif,

text/html или application/x-javascript.

Метод POST может включать форму со следующим заголовком Content-

Type:

POST /chat/chatroom.cgi НТТР/1.0

User-Agent: Mozilla/3.0C

Content-Type: application/x-www-form-urlencoded

Различные типы представления содержимого, используемые в Content-Type,

должны быть зарегистрированы организацией 1ANA.

• Content-Encoding. Заголовок Content-Encoding указывает, как было моди-

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

в формат, указанный в заголовке содержимого Content-Type. Кодирование

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

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

206

Часть

III.

Web-протоколы

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

тель должен располагать соответствующей технологией декодирования. Со-

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

gzip,

может со-

держать заголовок

Content-Encoding: x-gzip

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

согласно документу RFC 1590.

• Content-Length. Заголовок Content-Length указывает на длину тела содер-

жимого в байтах. Длина содержимого важна для обеспечения полной доставки

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

жет использоваться в качестве

валидатора

для сравнения кэшированного со-

держания с текущей его версией. Без заголовка Content-Length в запросе кли-

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

дачи запроса. В разделе 6.2.2 мы рассмотрели пример запроса POST, исполь-

зующего заголовок Content-Length. Если ответ генерируется динамически,

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

держимого. Поскольку длина содержимого Content-Length является значени-

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

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

динамических ответов заголовок Content-Length опускается. Если динамиче-

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

держимого может быть известна. В НТТР/1.0 в качестве индикатора конца со-

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

• Expires. Заголовок Expires предоставляет отправителю возможность заявить,

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

занного в заголовке. Клиент не должен кэшировать ответ позже даты, задан-

ной в заголовке Expires. Разница

между хранением

ресурса в кэше и

кэширова-

нием

весьма существенна. Ответ может храниться (т.е. удерживаться) в кэше и

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

возвращен

как ответ без

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

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

хранения ассоциируется с ресурсом, а не с сообщением. Сервер может отпра-

вить сообщение

НТТР/1.0 200

ОК

Server: Microsoft-IIS/4.0

Date:

Mon, 04 Dec 2000 18:16:45 GMT

Expires: Tue, 05 Dec 2000 18:16:45 GMT

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

• Last-Modified. Заголовок Last-Modified указывает время последнего измене-

ния ресурса. Если ресурсом является статический файл, то этим значением

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

чески генерируемый ресурс может иметь время Last-Modified, совпадающее

со временем создания сообщения-ответа сервером. Фактически время Last-

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

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

храпения. Заголовок Last-Modified в ответе подсказывает получателю срав-

нить это значение со значением Last-Modified кэшированной версии, чтобы

проверить, не устарел ли кэшированный ресурс. Наличие заголовка Last-

Глава

Структура

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

207

Modified трактуется некоторыми кэшами в НТТР/1.0 как указание, что содер-

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

dified для динамически сформированного содержимого не имеет особого

смысла. В главе 7 (раздел 7.3.2) мы более подробно обсудим назначение заго-

ловков, связанных с кэшированием.

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

НТТР/1.0 200

ОК

Date:

Sun,

21 May

2000 08:09:12

GMT

Last-Modified: Sun,

21 May

2000 07:00:25

GMT

6.2.4, Классы ответов НТТР/1.0

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

три поля: номер версии протокола сервера, код ответа и поясняющая фраза на ес-

тественном языке. Запрос на сервере может быть успешно обработан, вызвать от-

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

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

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

тов.

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

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

относятся: информационный класс, коды ответов для которого начинаются с 1 (за-

писываются как 1хх); класс успешного выполнения запроса (2хх); класс переадре-

сации (Зхх); класс ошибок клиента (4хх); класс ошибок сервера (5хх).

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

Протокол FTP [PR85] имеет схожий механизм кодов ответов. Изначально в HTTP

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

класс (1хх). Выбор первоначальных четырех классов ответов был в определенном

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

кола. Однако адаптация хорошо известного и понятного механизма послужила хо-

рошей отправной точкой. Хотя теоретически протокол допускает создание догюл-

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

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

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

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

фраза на естественном языке, называемая

строкой

описания

(reason

phrase), кото-

рая облегчает отладку и разработку приложений. Строка описания похожа на

текст, ассоциированный с кодом ответа в SMTP. Некоторые браузеры отображают

строку описания. Однако между кодами ответов в SMTP и в HTTP имеются раз-

личия. Каждая из трех цифр в коде ответа SMTP имеет специальное значение, как

указано в Приложении Е документа RFC 821. Первая цифра обозначает класс от-

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

вете,

а третья цифра дает окончательную степень детализации. В отличие от пер-

вой и второй цифр, третья цифра не имеет специалыюго смысла, связанного с ее

значением. Вторая цифра в коде ответа SMTP имеет значение

для синтаксиче-

ской информации,

для ответов, несущих дополнительную информацию, 2 для ин-

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

ции. В HTTP же вторая и третья цифры не несут какой-либо дополнительной ин-

формации. Коды ответов в каждом классе получали последовательные номера.

В то время как коды ответов стандартизованы, строки состояния не являются

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

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

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

404 Not Found (Не найдено) означает то же самое, что 404 Missing Resource (Ре-

сурс отсутствует) или 404 Kaanavillai.

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

же1ни'1,

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

определяется первой цифрой кода. Каждый класс ответа х имеет хОО в качестве от-

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

тен,

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

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

торый был определен в НТТР/1.1. Сервер-посредник НТТР/1.0 может не знать,

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

рактовать его как код ответа 200 ОК и не должен кэшировать ответ. HTTP-прило-

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

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

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

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

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

ИНФОРМАЦИОННЫЙ КЛАСС ОТВЕТОВ

Хотя информационный класс ответов был определен в НТТР/1.0, в действи-

тельности коды ответов не выделялись до появления НТТР/1.1. Это является при-

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

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

экспериментальных приложений. Ко времени формализации НТТР/1.1 информа-

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

определен и в настояшее время применяется. Класс 1хх кодов состояния ответов

подробнее рассматривается в главе 7 (раздел 7.2.3).

КЛАСС ОТВЕТОВ УСПЕШНОГО ВЫПОЛНЕНИЯ

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

рирует ответ, принадлежащий к классу успешного выполнения. Это не означает,

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

вюночает соответствующий ответ на основе метода запроса. Код успешного выпол-

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

код ответа 200 ОК вполне применим к сообщению с пустым телом, поскольку тело

сообщения может иметь нулевую длину.

В НТТР/1.0 имеются следующие четыре кода ответов 2хх:

• 200 ОК. Ответ 200 ОК возвращается, если запрос выполнен успешно. В зави-

симос'ги от метода запроса в ответ включается различное количество деталей.

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

няюищм метод GET к ресурсу. В случае запроса HEAD ответ 200 ОК будет

содержать только метаданные.

• 201 Created. Этот ответ возвращается, если ресурс был успешно создан в ре-

зультате выполнения запроса POST. Хотя это официально и не определено

в НТТР/1.(), метод PUT может также возвращать ответ 201 Created, если за-

нрашиваемьн! URI не существовал и был успешно создан.

• 202 Accepted. Ответ 202 Accepted 1Н1формирует клиента, что запрос был по-

лучен, но пока не обработан полностью. Хотя позднее запрос может закон-

читься неудачей, главное назначение этого кода ответа — дать возможность

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

агенту пользователя продолжить вьн1олне1П4е своей задачи, не ожидая завер-

шения выполнения действия исходным сервером. Код 202 Accepted был спе-

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

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

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

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

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

завершиться. Если могут быть сформированы достоверные оценки, то они на

естественным языке включаются в тело ответа.

• 204 No Content. Код 204 No Content является сигналом от исходного сервера,

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

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

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

сервере; т.е. щелчок па активных участках может инициировать запрос. Если

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

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

правки сервером ответа 204 No Content, который браузер интерпретирует как

«изменений не требуются».

КЛАСС ОТВЕТОВ, СВЯЗАННЫХ С ПЕРЕАДРЕСАЦИЕЙ

Коды класса ответов, связанные с переадресацией, используются для информи-

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

тельное действие. Код ответа для переадресации может затем привести к успешно-

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

довательных переадресаций. Для предотвращения этой возможности количество

переадресаций ограничивается. Ограничения определяются той стратегией, кото-

рую реализует сервер. Имеется четыре кода ответов, связанных с переадресацией:

• 300 Multiple Choices. Код 300 Multiple Choices главным образом выполняет

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

зуют этот код ответа. Информация о доступности ресурса в другом месте

включается в ответ 300 Multiple Choices с помощью заголовка ответа Loca-

tion.

Агент пользователя использует информацию о местонахождении и авто-

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

• 301 Moved Permanently. Код 301 Moved Permanently используется для ука-

зания, что запрашиваемый ресурс имеет^новое местонахождение. Это полезно

для автоматической нереадресации запросов GET и HEAD (но не POST) дру-

гому сайту. Метод POST, в отличие от методов GET и HEAD, может потребо-

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

меняет содержимое на исходном сервере.

• 302 Moved Temporarily. Код 302 Moved Temporarily является разновидно-

стью ответа 301 Moved Permanently в том смысле, что запрашиваемый ресурс

также был перемещен, но не постоянно. В отличие от ответа 301 Moved

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

старый URL. В то время как ответы 301 Moved Permanently по умолчанию

являются кэшируемыми, ответы 302 Moved Temporarily не кэшируются.

• 304 Not Modified. Код ответа 304 Not Modified возвращается, если время по-

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

значение для кэширования, о чем подробнее рассказывается в главе И.