Сообщение-ответ

Ниже приведен пример типичного ответа, генерируемого HTTP-сервером.
НТТР/1.1 200 ОК Connection: close
Date: Thu. 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon. 22 Jun 1998 09:23:24 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data …)

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

Теперь обратимся к строкам заголовка. Сервер использует строку Connection: close для уведомления клиента о том, что ТСР-соединение будет закрыто после того, как окончится пересылка объекта. Строка The Date: содержит дату и время создания ответа. Обратите внимание, что эта дата не относится к созданию или последнему изменению объекта, а указывает момент извлечения объекта из места его хранения и включения в тело сообщения. Строка Server: говорит о том, что сообщение было создано сервером Apache, и она аналогична строке User-agent: в сообщении-запросе. Строка Last-Modified: содержит дату и время создания или последнего изменения объекта. Как мы увидим немного позже, содержимое строки Last-Modified: крайне важно для кэширования объектов как на локальных клиентах, так и на сетевых кэш-серверах (часто называемых прокси-серверами). Строка Content-Length: содержит размер пересылаемого объекта в байтах, а строка Content-Type: указывает на то, что объект является текстом в формате HTML (обратите внимание, что тип объекта определяется содержимым строки Content-Type: и не зависит от расширения файла).

Если сервер получает запрос, в котором указана версия НТТР/1.0, постоянное соединение не будет использоваться, даже при поддержке сервером протокола НТТР/1.1. Это необходимо потому, что спецификация HTTP 1.0 не предусматривает постоянных соединений.

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

Как можно убедиться, наш пример также полностью соответствует приведенному формату. Теперь скажем несколько слов о том, что означают поля кода состояния и информации о состоянии. Эти два поля взаимосвязаны и фактически отражают результат обработки запроса. Ниже приведены несколько наиболее часто встречающихся пар, содержащих код состояния и информацию об этом состоянии.

200 OK:
Запрос успешно обработан, объект получен и включен в ответ.
301 Moved Permanently:
Объект был перемещен; новый URL-адрес указан в строке ответа Location:.
Программа клиента автоматически выполнит запрос по новому адресу.
400 Bad Request:
Общая ошибка, вызванная невозможностью интерпретации запроса сервером.
404 Not Found:
Запрашиваемый документ не найден на сервере.
505 HTTP Version Not Supported:
Указанная в запросе версия HTTP не поддерживается сервером.

Мы рекомендуем вам на практике ознакомиться с ответными HTTP-сообщениями. Для этого организуйте удаленный доступ к какому-либо серверу с помощью программы Telnet, а затем введите однострочный запрос объекта, находящегося на этом сервере. Например, для UNIX-машины это может выглядеть следующим образом:

telnet _www.eurecom.fr 80
GET /-ross/index.htnil HTTP/1.0

После ввода второй строки следует дважды нажать клавишу ввода. В результате будет установлено ТСР-соединение с портом 80 хоста _www.eurecom.fr и отправлен запрос в виде команды GET. На вашем экране появится базовый HTML-файл домашней web-страницы профессора Росса. Если вам не нужно содержимое файла, достаточно заменить во второй строке слово GET словом HEAD. Теперь замените путь /-ross/index.html на/-ross/banana.html и посмотрите, какой ответ вы получите в этом случае.

В этом разделе мы изучили несколько типичных строк заголовка, которые могут использоваться в запросах и ответах протокола HTTP. В спецификациях HTTP (особенно 1.1) содержатся описания гораздо большего количества строк заголовка, используемых браузерами, web-серверами и сетевыми кэш-серверами. Мы столкнемся с несколькими новыми строками в процессе изучения web-кэширования в конце этой главы; тем не менее за подробной информацией о НТТР/1.1 следует обратиться к. Замечательным введением в проблематику web является.

Каким образом браузер определяет строки заголовка, которые нужно включить в запрос? Каким образом сервер определяет строки заголовка, которые нужно включить в ответ? Для браузера включаемые строки зависят от фирмы-разработчика, версии продукта (например, браузер, разработанный для спецификации НТТР/1.0, не сможет генерировать строки, характерные для спецификации НТТР/1.1), пользовательских настроек (например, языка), наличия на компьютере версии (возможно, устаревшей) запрашиваемого объекта. Аналогичная ситуация характерна для серверов: существуют различные программные продукты, их версии, настройки, совместно влияющие на включаемые строки заголовка.