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

Наши определения различных терминов HTTP идентичны тем, которые содержатся в двух документах RFC, описывающих НТТР/1.0 и НТТР/1.1 (соответственно RFC 1945 [BLFF96] и RFC 2616 [FGM+99]). Где это необходимо, мы предоставим дополнительные пояснения и примеры. Большинство терминов было определено в главе 1. Здесь мы более подробно остановимся на четырех важных понятиях: сообщение, содержимое, ресурс и агент пользователя.

СООБЩЕНИЕ

НТТР-сообщение представляет собой последовательность байтов, передаваемых но соединению транспортного уровня. Сообщение — это основная единица коммуникационного взаимодействия в HTTP. НТТР-сообщение может быть запросом, передаваемым от клиента серверу, или ответом, отправляемым сервером клиенту. Сообщение-запрос начинается со строки запроса, в то время как сообщение-ответ начинается со строки состояния. Сообщения запроса и ответа могут иметь пуль или более заголовков, отделенных от необязательного тела сообщения двумя символами: возврата каретки (CR) и перевода строки (LF).

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

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

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

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

GET /motd HTTP/1.0

Date: Wed, 22 Маг 2000 08:09:01 GMT

Pragma: No-cache

From: gorby@moskvax.com

User-Agent: Mozilla/4.03

CRLF

также представленным на рис. 6.1, методом запроса является GET, запрашивается ресурс /motd, а клиентской версией протокола является НТТР/1.0. Заголовки Date, Pragma являются общими заголовками, такие заголовки могут присутствовать в запросах и ответах. Заголовки From и User-Agent являются заголовками запроса и могут присутствовать только в сообщениях-запросах. Общие заголовки, заголовки запроса и заголовки содержимого подробнее будут рассмотрены в разделе 6.2.3. Это сообщение-запрос заканчивается последовательностью CRLF, состоящей из символов возврата каретки и перевода строки. В этом НТТР-сообщении пет информационного содержания (тела содержимого).

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

На рис. 6.2 показано сообщение-запрос с телом сообщения. Для создания ресурса /motd используется метод PUT. За методом запроса следует один общий заголовок (Date) и два заголовка запроса (From и User-Agent). Сообщение-запрос имеет два заголовка содержимого (Content-Length и Allow). Первый из них указывает длину содержимого, а второй задает методы, которые могут быть применены к pe- cypcy /motd. Тело содержимого состоит из строки Welcome to Comer’s Vax.

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

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

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

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

Сообщение-ответ начинается со строки состояния, которая содержит помер версии HTTP сервера и код ответа. Далее следуют необязательный общий заголовок, заголовок ответа, а также необязательное тело сообщения. Следует заметить, что из-за наличия промежуточных звеньев окончательное полученное сообщение не обязательно будет отражать помер версии протокола исходного сервера. На рис. 6.3 показано сообщение-ответ для описанного выше запроса GET.

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

НТТР/1.0 200 0K

Date: Wed, 22 Mar 2000 08:09:03 GMT Server: Netscape-Enterprise/3.5.1 Content-Length: 23 CRLF

Welcome to Comer’s Vax

Строка состояния в сообщении-ответе указывает, что сервер поддерживает НТТР/1.0, а код ответа 200 OK указывает на успешное выполнение запроса. Сооб- щеиие-ответ содержит общий заголовок Date и заголовок ответа Server. Заголовок содержимого Content-Length отражает длину тела содержимого. За последовательностью CRLF следует тело содержимого, которое в этом примере представляет собой строку Welcome to Comer’s Vax.

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

СОДЕРЖИМОЕ

НТТР/1.0 определяет содержимое как представление ресурса, которое заключено в сообщении запроса или ответа. Содержимое состоит из заголовков содержимого и необязательного тела содержимого. Заголовки содержимого состоят из метаданных о содержимом. Длина тела содержимого может быть задана в заголовке Content-Length. Очевидно, что ответ, у которого значение Content-Length равно пулю, не будет иметь тела содержимого. Определение содержимого несколько отличается в протоколах НТТР/1.0 и НТТР/1.1 главным образом из-за введения механизма согласования содержимого (описанного в главе 7, разделе 7.9).

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

РЕСУРС

НТТР/1.0 [BLFF96J определяет ресурс как «сетевой объект данных или сервис, который может быть идентифицирован унифицированным идентификатором ресурса (URI)». Термин «сетевой» означает, что объект данных или сервис могут располагаться в любой точке сети, а доступ к нему осуществляется через сетевое соединение. Решение расширить определение ресурса сервисом имело важное значение. Объект данных может быть статическим или генерироваться динамически, тогда как сервис может нредставлять собой любое приложение, которое просто использует Web в качестве транспортного средства для инициирования сервиса и предоставления ответа. Например, рассмотрим Web-сайт, который возвращает текущие котировки акций. Цепы на акции постоянно меняются, и ресурс http://www.cnnfn.com/ quote=T? будет выдавать текущую цену акций AT&T. Сервис предоставления котировок может использовать любые внутренние механизмы для получения текущей цены акций. Оп просто использует Web как механизм для передачи запроса (определенного набора акций) и ответа (текущей цены каждой из акций).

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

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

Часто информация об агеите пользователя посылается как часть запроса в заголовке User-Agent (описанном более подробно в разделе 6.2.3). Заголовок содержит такую информацию, как названия браузера и операционной системы компьютера. В качестве примера приведем: Mozilla/3.01 (X11; 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).

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100