Приложение 5.
Протокол HTTP

Введение

Протокол HTTP (Hypertext Transfer Protocol, протокол передачи гипертекстов) — это протокол прикладного уровня для распределенных гипертекстовых информационных систем. Помимо передачи гипертекстов он может применяться и в других областях, таких, как серверы имен и распределенные системы управления объектами, но для наших целей важно то, что на этом протоколе с момента своего появления в 1990 г. и по сей день базируется World Wide Web. Приведенное ниже краткое его описание основано на спецификации HTTP/1.1 (RFC 2616 , июнь 1999 г.). Место HTTP в иерархии протоколов Сети показано на рисунке.

HTTP является протоколом типа запрос/отклик. Клиент посылает серверу запрос, состоящий из типа запроса, URI и версии протокола, за которыми следует сообщение, содержащее модификаторы запроса, клиентскую информацию и, возможно, тело запроса. Сервер отвечает строкой состояния, содержащей версию протокола и код состояния, за которой следует сообщение, содержащее серверную информацию, метаинформацию и, возможно, тело сообщения.

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

• Прокси-сервер (или сервер полномочий) принимает запрос клиента, включая полный URI, переписывает все сообщение или часть его и передает исправленный запрос серверу, указанному в URI.
• Шлюз располагается над сервером и при необходимости транслирует запросы в протокол более низкого уровня, поддерживаемый сервером.
• Туннель не изменяет передаваемых сообщений, а используется при передаче данных через посредника типа брандмауэра (firewall).

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

Сообщения HTTP

Сообщения HTTP состоят из запросов клиента к серверу и откликов сервера к клиенту. Оба типа сообщений состоят из:

• стартовой строки, определяющей тип сообщения;
• нуля или более полей заголовка (кратко называемых просто заголовки);
• пустой строки, содержащей только символы CR LF и указывающей на конец заголовков;
• необязательного тела сообщения.

Каждое из полей заголовков имеет формат

имя_поля ":" значение_поля

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

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

имя_поля ":" значение1 "," значение2

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

Поля заголовка

Таблица П5.2. Поля заголовка запроса

Поле	Описание
Accept	Задает типы файлов MIME, приемлемые в отклике. Пример: Accept: text/*, text/html.
Accept-Charset	Задает кодировки символов, приемлемые в отклике. Пример: Accept-Charset: iso-8859-5, unicode-1-1.
Accept-Encoding	Задает кодировки содержимого, приемлемые в отклике. Пример: Accept-Encoding: compress, gzip.
Accept-Language	Задает естественные языки, приемлемые в отклике. Пример: Accept-Language: ru, en-us, en.
Authorization	Задает имя и пароль пользователя для авторизации доступа к ресурсу согласно RFC 2617 .
Expect	Указывет, что клиент ожидает от сервера определенной реакции. Пример: Expect: 100-continue.
From	Задает адрес электронной почты администратора клиента. Пример: From: webmaster@w3.org.
Host	Задает имя и, возможно, порт хост-компьютера, на котором расположен запрашиваемый ресурс.Пример: Host: www.mysite.com.
If-Match	Используется в условных методах: запрошенный ресурс передается, только если он содержит один из заданных тегов. Пример: If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz".
If-Modified-Since	Используется в условных методах: запрошенный ресурс передается, только если он был изменен после указанной даты. Пример: If-Modified-Since: Sat, 29 Oct 1999 19:43:31 GMT.
If-None-Match	Используется в условных методах: запрошенный ресурс передается, только если он не содержит ни одного из заданных тегов. Пример: If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz".
If-Range	Используется в условных методах: запрошенный ресурс передается целиком, если он был изменен после указанной даты: иначе передается недостающая часть ресурса. Пример: If-Range: Sat, 29 Oct 1999 19:43:31 GMT.
If-Unmodified-Since	Используется в условных методах: запрошенный ресурс передается, только если он не был изменен после указанной даты. Пример: If-Unmodified-Since: Sat, 29 Oct 1999 19:43:31 GMT.
Max-Forwards	Задает максимальное количество шлюзов и прокси-серверов, которые могут быть использованы для передачи сообщения следующему серверу. Пример: Max-Forwards: 5.
Proxy-Authorization	Задает имя и пароль пользователя для авторизации доступа к прокси-серверу согласно RFC 2617 .
Range	Задает диапазон номеров байтов в теле сообщения. Пример: Range: bytes=0-499.
Referer	Задает URI ресурса, из которого был получен URI запроса. Позволяет серверу создавать списки обратных ссылок и отслеживать устаревшие ссылки. Пример: Referer: http://www.mysite.com/index.html.
TE	Указывает, какие кодировки расширений принимаются в отклике, и принимаются ли кодированные прицепные поля. Пример: TE: trailers, deflate.
User-Agent	Информация об обозревателе, пославшем запрос. Пример: User-Agent: CERN-LineMode/2.15 libwww/2.17b3.

Таблица П5.3. Поля заголовка отклика

Поле	Описание
Accept-Ranges	Указывает, может ли сервер передавать диапазоны байтов. Пример: Accept-Ranges: none.
Age	Возвращает время в секундах, прошедшее с генерации отклика исходным сервером. Пример: Age: 230.
ETag	Содержит тег текущего сообщения. Пример: ETag: "xyzzy".
Location	Возвращает полный URI запрошенного ресурса. Пример: Location: http://www.mysite.com/index.html.
Proxy-Authenticate	Сообщает, что прокси-сервер требует авторизации, и возвращает схему авторизации согласно RFC 2617 .
Retry-After	Сообщает, как долго еще ресурс будет недоступен. Пример: Retry-After: Fri, 31 Dec 1999 23:59:59 GMT.
Server	Содержит информацию о программном обеспечении сервера, пославшего отклик. Пример: Server: CERN/3.0 libwww/2.17.
Vary	Содержит набор полей заголовка запроса, который полностью определяет возможность использования кэша. Пример: Vary: *.
WWW-Authenticate	Сообщает, что ресурс требует авторизации, и возвращает схему авторизации согласно RFC 2617 .

Таблица П5.4. Поля заголовка тела

Поле	Описание
Allow	Содержит список методов, поддерживаемых запрошенным ресурсом. Пример: Allow: GET, HEAD, PUT.
Content-Encoding	Задает способ кодирования тела сообщения. Пример: Content-Encoding: gzip.
Content-Language	Задает естественный язык, на котором написано тело сообщения. Пример: Content-Language: ru.
Content-Length	Задает размер тела в байтах. Пример: Content-Length: 3495.
Content-Location	Содержит URI тела сообщения, когда он отличен от URI запроса. Пример: Content-Location: images/1234.gif.
Content-MD5	Содержит контрольное значение MD5, используемое для проверки целостности тела сообщения согласно RFC 1864 .
Content-Range	Содержит диапазон байтов в теле сообщения. Пример: Content-Range: bytes 0-499/1234.
Content-Type	Содержит тип MIME тела сообщения. Пример: Content-Type: text/html; charset=ISO-8859-4.
Expires	Дата и время, после которых содержание отклика становится устаревшим. Пример: Expires: Thu, 01 Dec 1999 16:00:00 GMT.
Last-Modified	Дата и время последней модификации передаваемого ресурса. Пример: Last-Modified: Tue, 15 Nov 1999 12:45:26 GMT.

Типы запросов

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

метод " " URI_запроса " " версия_HHTP CR LF

Здесь метод — это название типа запроса, URI_запроса — это либо URI запрашиваемого ресурса, либо символ "*" в тех случаях, когда запрос не связан с конкретным ресурсом, а версия_HHTP выглядит так:

"HTTP/" цифра "." цифра

Типичные примеры строк запроса:

GET http://www.mysite.com/index.html HTTP/1.1
OPTIONS * HTTP/1.1

Запрос OPTIONS

Метод OPTIONS представляет собой запрос информации об условиях коммуникации, доступных в цепочке запрос/отклик для данного URI запроса. Он позволяет клиенту определить опции и/или требования, связанные с данным ресурсом, не выполняя никаких операций с ресурсом.

Если URI запроса задано символом "*", то запрос относится к серверу, а не к конкретному ресурсу, и позволяет запросить возможности сервера.

Запрос GET

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

Этот метод является условным, если в его заголовке заданы поля If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Условный метод отличается тем, что запрошенный ресурс будет возвращен только в том случае, когда он удовлетворяет заданному условию.

Запрос HEAD

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

Запрос POST

Метод POST используется в следующих случаях:

• создание аннотаций к имеющимся ресурсам;
• посылка сообщения на доску объявлений, в группу новостей, список почтовой рассылки и т. п.;
• передача блока данных, например, результата заполнения формы, программе обработки данных;
• добавление записей в базу данных.

Суть данного метода состоит в том, что тело запроса передается серверу, и тот интерпретирует его в зависимости от URI запроса (обычно это адрес программы, которая должна обработать данные, содержащиеся в теле запроса). Например, если URI запроса содержит имя CGI-сценария, то этот сценарий будет запущен на сервере и в качестве параметра ему будет передано тело запроса POST.

Запрос PUT

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

Запрос DELETE

Метод DELETE используется для удаления ресурса, имеющего заданный URI.

Запрос TRACE

Метод TRACE используется в целях отладки и диагностики. Он состоит в посылке сообщения по заданной цепочке и в приеме обратного квитирования этого сообщения.

Запрос CONNECT

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

Формат отклика

После получения запроса и его интерпретации сервер отправляет клиенту отклик следующего формата

строка_состояния
заголовки
CR LF
тело_сообщения

где строка_состояния имеет вид

версия_HTTP " " код_состояния " " описание CR LF

Здесь версия_HTTP имеет тот же формат, что и в запросе, коды состояния описаны ниже, а описание — это строка, содержащая краткое текстовое описание кода_состояния.

Типичный пример отклика, возвращающего запрошенный HTML-документ:

HTTP/1.1 200 OK
Date: Wednesday, 02-Feb-00 23:04:12 GMT
Server: NCSA/1.3
MIME-version: 1.0
Last-modified: Monday, 15-Nov-99 23:33:16 GMT
Content-type: text/html
Content-length: 2345
 пустая строка
<HTML><HEAD>…</HTML>

Коды состояния

Код состояния — это целое число из трех цифр, которое указывает на результат выполнения запроса. Первая цифра этого числа определяет класс отклика:

1. Информационные сообщения (запрос получен, идет его обработка).
2. Успех (запрос был получен, понят и понят сервером).
3. Перенаправление (для завершения запроса необходимы дальнейшие действия обозревателя).
4. Ошибка клиента (запрос неверно составлен или не может быть выполнен).
5. Ошибка сервера (сервер не смог исполнить, по-видимому, верный запрос).

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