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

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

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

5,5.

Резюме

Протокол Internet Protocol обеспечивает базовый сервис по доставке пакетов

через различные физические среды передачи данных. Наличие простого, открытого

стандарта способствовало быстрому превращению Internet во всемирную коммуни-

кационную инфраструктуру. Более сложные сервисы поддерживаются протокола-

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

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

реализации на других уровнях. Протокол Transmission Control Protocol предостав-

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

ных последовательностей байтов между двумя хостами. Сокеты служат основными

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

идентифицироваться по доменным именам и по IP-адресам. Система именования

доменов Domain Name System предоставляет простой, расширяемый способ преоб-

разования одного из этих представлений в другое. Все вместе IP, TCP и DNS под-

держивают множество Internet-приложений, включая Telnet, передачу файлов,

электронную почту и группы новостей. Эти приложения основываются па прото-

колах Telnet, FTP, SMTP и NNTP, которые были предшественниками Web и ока-

зали влияние на HTTP.

Структура и описание

протокола HTTP

Любой протокол

—

это язык со своей грамматикой, синтаксической структурой,

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

щими, как следует интерпретировать ноля сообщений. Hypertext Transfer Protocol

(HTTP) представляет собой протокол типа запрос-ответ, составляющий основу

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

Protocol (FTP) и Telnet. Однако в отличие от этих протоколов, HTTP не сохраняет

своего состояния. HTTP появился в 1990 г., а с 1995 г стал протоколом, с помощью

которого передается значительная часть трафика Internet.

Важно понимать разницу между HTTP и Всемирной паутиной. Как упомина-

лось в первой главе, Web состоит из трех семантических частей: протокола HTTP,

языка гипертекстовой разметки (HTML) и схемы именования с помощью унифи-

цированных идентификаторов ресурсов (URI). В Web используются несколько

важных программных компонентов (браузеры с графическим пользовательским

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

вуют между собой с помощью протокола HTTP. Web-компоненты также использу-

ют HTTP как механизм коммуникационного взаимодействия для обращения к ре-

сурсам, доступным через другие протоколы, например, FTP или Telnet.

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

личных языках и с различными наборами символов. Синтаксис HTTP-сообщения

основан на стандарте MIME — Multipurpose Internet Mail Extensions [FB96a,

FB96bJ. Содержимое НТТР-сообщепия слепо воспринимается протоколом

—

ника-

кой интерпретации при этом не производится

Материал, изложенный в этой главе, основывается па документе RFC 1945

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

существенны для понимания HTTP. Документ RFC 1945 отражает общие принципы

использования HTTP в середине 90-х годов. Текущей версией протокола HTTP на

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

посвящена НТТР/1.1 и отличиям между НТТР/1.0 и НТТР/1.1. Наше решение

представить описание НТТР/1.0 и НТТР/1.1 в отдельных главах является не слу-

чайным. Предварительное рассмотрение НТТР/1.0 дает читателю возможность по-

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

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

шее рассмотрение НТТР/1.1 позволяет познакомиться с эволюцией протокола.

В этой главе будет рассмотрено, как HTTP развивался с первых дней возникно-

вения Web. Мы начнем с обзора протокола HTTP, познакомимся с его истоками,

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

182

Часть

III.

Web-протоколы

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

Web,

и использовал некоторые их идеи.

В следующем разделе будут рассмотрены «строительные блоки» протокола: эле-

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

щениях) и различные классы ответов. Имеющийся на настоящий момент набор по-

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

представляют лишь небольшое подмножество операций, осуществляемых с исполь-

зованием HTTP. Понимание основных элементов протокола поможет оценить все

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

После рассмотрения вопросов, связанных с возможностями расширения прото-

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

пользованием HTTP. Будет рассмотрен протокол Secure Socket Layer (SSL) и его

использование для обмена информацией в Web. Как и в других коммуникацион-

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

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

протокола HTTP и поговорим о значении номера версии протокола. Завершается

глава обсуждением принципов и практики применения НТТР/1.0.

6.1.

Обзор HTTP

Обзор HTTP удобно осуществлять в историческом контексте. HTTP эволюцио-

нировал вместе со Всемирной паутиной и ее двумя другими компонентами: URI и

HTML. В процессе эволюции HTTP можно выделить два этана:

• от появления первой спецификации НТТР/0.9 до версии HTTP/LO (этот пе-

риод занял четыре года);

• от появления HTTP/LO до появления HTTP/L1 (еще четыре года).

В таблице 6.1 приведена частичная хронология публикации проектов и оконча-

тельных версий стандартов.

Таблица 6.1. Хронология публикации документов, относящихся к HTTP

Дата

Март 1990 г.

Январь 1992 г.

Февраль 1992 г.

]

Декабрь 1992 г.

Февраль 1993 г.

Март 1993 г.

Июнь 1993 г.

Октябрь 1993 г.

Ноябрь 1993 г.

Март 1994 г.

Май 1996 г.

Документ 1

Документ CERN с предложениями по созданию Web |

Спецификация НТТР/0.9 |

W3 и WAIS/X.500

Предложения по добавлению MIME в HTTP |

Универсальные идентификаторы документов (UDI

—

Universal

Document Identifier) для сетевого использования |

Первая версия рабочего проекта НТТР/1.0 |

HTML (спецификация 1.0) |

Спецификация URL |

Вторая версия рабочего проекта НТТР/1.0 |

URI в WWW

Информационный материал по НТТР/1.0 (RFC 1945)

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

Дата

Январь 1997 г.

Июнь 1999 г.

2001 г.

Документ 1

Предложение по стандарту НТТР/1.1 (Proposed Standard, RFC 2068)

Рабочий проект стандарта НТТР/1.1 (Draft Standard, RFC 2616)

Официальный стандарт НТТР/1.1 (Formal Standard) '

HTTP был предложен в марте 1990 г. Тимом Бернерс-Ли, работавшим тогда

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

ции посредством гиперссылок [Nel67J. Самая ранняя версия протокола НТТР/0.9^

была впервые опубликована в январе 1992 г. в списке рассылки www-talk [BL92a],

хотя его реализация датируется 1990 годом. Спецификация НТТР/0.9 привела

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

разделению функций между этими двумя компонентами. Были задокументирова-

ны основные синтаксические и семантические положения, а НТТР/0.9 получил

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

планировалась в то время. Основное внимание тогда было сосредоточено на поис-

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

конкурирующими системами, такими как Gopher и Archie.

Гипертекст приобрел популярность в 1980-е годы в качестве средства навигации

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

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

ние линейности. Читатель может перемещаться от одной части документа к другой

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

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

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

документы.

В декабре 1992 г. в списке рассылки www-talk завязалась дискуссия о возмож-

1ЮСТИ использования MIME в глобальных информационно-поисковых системах,

таких как Wide Area Information Servers (WAIS) и Web. Развивавшийся в то время

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

сообщений, состоящих из нескольких разнородных частей по электронной почте.

HTTP-ответы могли возвращаться в виде MIME-сообщепий. Первая предвари-

тельная спецификация НТТР/1.0 появилась в марте 1993 г. В июне 1993 г. в про-

екте спецификации [BLC93J было предложено сделать HTML одним из типов со-

держимого MIME. Позже, в октябре 1993 г., после дискуссии в рабочей группе

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

ных указателей ресурсов (URL

—

Uniform Resource Locators) [BL93b].

После этого вышло несколько рабочих проектов документов НТТР/1.0.

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

документ RFC 1945 [BLFF96], что послужило основой для реализации большинст-

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

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

RFC 2068 с предложением по стандарту (Proposed Standard), а в июне 1999 г. был

опубликован документ RFC 2616 [FGM^99] в качестве проекта стандарта (Draft

Standard) НТТР/1.1. Официальный стандарт^ HTTP должен появиться в 2001 г.

^ По сложившейся традиции начальной версии протокола до проведения широкого обсуж-

дения, доработки и распространения присваивают номер, меньший 1.

^ На время редактирования книги официальный стандарт не был принят.

—

Прим.

ред.

^84

Часть

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

Обзор протокола HTTP в этом разделе осуществляется в двух аспектах:

• Свойства протокола. Здесь рассматриваются взаимосвязь HTTP с инфра-

структурой URI, система функционирования HTTP по принципу запрос-от-

вет, отсутствие сохранения информации о состоянии между запросами и по-

нятие метада1Н1ых (информация о ресурсе).

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

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

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

уровня.

6.1.1.

Свойства протокола

в этом разделе будут рассмотрены некоторые основные свойства HTTP. К ним

относятся:

• Глобальные URI. HTTP основывается на механизме именования URI. HTTP

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

• Обмен по схеме запрос-ответ. HTTP-запросы отправляются клиентами, по-

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

—

от клиента к серверу;

сервер не инициирует Web-трафик.

• Отсутствие сохранения состояния. Состояние между запросами и ответами

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

как независимый обмен сообщениями.

• Метаданные ресурсов. Информация о ресурсах часто включается в Web-

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

ПРИМЕНЕНИЕ ГЛОБАЛЬНЫХ URI

HTTP основывается на идее унифицированного идентификатора ресурса (URI

—

Uniform Resource Identifier) [BLFM98]. Механизм именования дает возможность

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

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

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

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

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

ложения или имени, по которому он известен. В этом смысле URI является комби-

нацией унифицированного указателя ресурса (URL — Uniform Resource Locator)

[BLMM94, Fie95] и унифицированного имени ресурса (URN — Uniform Resource

Name) [SM94]. URI представляет собой надмножество URL, URN и может быть

выражен одной из этих составляющих, либо обеими. Наиболее популярной фор-

мой URI является URL.

В качестве примера, поясняющего различия между URI, URL и URN, возьмем

эту книгу. Американское издание книги имеет ISBN 0-201-71088-9, присвоенный

Библиотекой Копфесса США. Номер ISBN гарантирова1пю уникален, отличается от

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

кации миллиона других книг. Только Библиотека Конгресса США решает, как при-

своить уникальный номер этой книге. Номер ISBN представляет собой URN для

этой книги; он именует книгу, но не предоставляет информацию о том, где книга мо-

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

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

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

этой книги было помещено на Web-сервер и стало доступным по HTTP. Местонахо-

ждение книги может быть указано с помощью URL http://www.research.att.com/

books/kandr.ps.gz. Книга также может быть доступной через ан.опимный FTP-cep-

вер в каталоге pub/bala на компьютере ftp.research.att.com. Таким образом, она

имеет альтернативный URL ftp://ftp.research.att.com/pub/balaAandr.ps.gz. Этот

URL задает местонахождение копии ресурса. Таким образом, URI книги может быть

представлен любым из упомянутых выше URL или URN (номером ISBN).

URI считается абсолютным, если строка начинается со схемы, за которой следует

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

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

Относительный URI не начинается с имени схемы. В самой первой спецификации

протокола HTTP, известной позднее как НТТР/0.9 [BL92a], было перечислено пять

схем: file, news, http, telnet, gopher. On также предвосхитил использование по мень-

шей мере еще двух (WAIS и Х-500) и зарезервировал схемы для них.

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

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

проса на ресурс обычно требуется несколько протоколов, таких как Domain Name

System (DNS) для определения IP-адреса хоста, на котором размещен ресурс, по

его доменному имени, и Transmission Control Protocol (TCP) для загрузки ресурса

по соединению транспортного уровня. Точно так же для идентификации одного ре-

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

Наиболее часто в Web используется схема http. Каждая схема имеет свой собст-

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

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

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

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

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

ны поверх HTTP. Возможность использовать не-НТТР URI, т.е. работать с ресур-

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

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

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

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

но используются другие протоколы, например, ftp. В качестве примеров не-НТТР

URI можно привести rtsp://cHps.foo.com/preview/audio, telnet://ox.aciri.org

и т.д. Столкнувшись с не-НТТР URI, браузер осуществляет синтаксический ана-

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

токола

—

RTSP (Real Time Streaming Protocol) и Telnet, соответственно.

ОБМЕН ЗАПРОСАМИ-ОТВЕТАМИ

Протокол HTTP задает синтаксис и семантику, в соответствии с которыми ком-

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

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

является запрос-ответным протоколом, в котором запрос — это сообщение, посы-

лаемое клиентом принимающему серверу. Принимающим может быть исходный

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

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

сообщение-ответ. Клиентом может выступать агент пользователя, нечто, иниции-

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

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

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

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

чение, изменение, создание или удаление ресурса. Ресурсом является объект,

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

фицированы и размещены в любом месте сети [BLFM98J.

Рассмотрим следующий HTTP-запрос:

GET /foo.html HTTP/1.0

Строка /foo.html идентифицирует запрашиваемый с помощью метода GET ре-

сурс.

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

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

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

точным, запрос приводит к применению метода GET к ресурсу, иде1ггифицируемо-

му /foo.html. В общем случае сообщение-запрос состоит из метода, URI, иденти-

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

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

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

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

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

НТТР/1.0 200 ОК

Date:

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

Last-Modified: Wed, 22 Маг 2000 02:16:33 GMT

Content-Length: 3913

<3913 байтов текущего содержимого /foo.html>

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

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

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

вестная как строка состояния, содержит номер версии HTTP и код ответа 200 ОК,

указывающий, что запрос выполнен успешно. Заголовок ответа Date указывает

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

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

ние-ответ (3913 байта), соответственно. В версии НТТР/0.9 протокола не преду-

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

Не все ноля заголовка являются информационными. Некоторые ноля заголовка

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

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

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

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

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

ставляет собой черный ящик, содержащий ресурсы, идентифицируемые URI. Ис-

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

нерирует ответ. Операции по чтению ресурса из файла и записи ответа обратно

клиенту «скрыты» внутри черного ящика. Подобное представление обобщает со-

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

просы с одним и тем же URI могут порождать различные ответы в зависимости от

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

менений в ресурсе.

HTTP является протоколом прикладного уровня, подобно FTP, Simple Mail

Transfer Protocol (SMTP) и Network News Transfer Protocol (NNTP), рассмотрен-

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

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

Глава

Структура

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

187

все известные реализации HTTP используют в качестве протокола транспортного

уровня протокол Transmission Control Protocol (TCP).

Сервер не может ответить

до

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

на сообщениями от клиента к серверу, а затем от сервера к клиенту. HTTP-сервер

может не

отвечать

на запрос. В этом смысле HTTP схож с другими протоколами

прикладного уровня, такими как Gopher [AAL+92J и WAIS [KM91J.

Мы обрисовали содержимое НТТР-взаимодействия между клиентом и серве-

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

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

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

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

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

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

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

несколько клиентов могут участвовать в НТТР-взаимодействии, не вызывая из-

лишней загрузки сети. Посредники подробно рассматривались в главе 3.

HTTP НЕ СОХРАНЯЕТ СВОЕГО СОСТОЯНИЯ

HTTP представляет собой протокол, не сохраняющий

своего

состояния (state-

less).

Это означает отсутствие сохранения промежуточного состояния между пара-

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

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

зующие HTTP, могут и осуществляют сохранение информации о состоянии,

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

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

формацию об IP-адресе клиента, отправившего последние десять запросов. Однако

сам протокол не осведомлен о предыдущих запросах и ответах. В протоколе не

предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие

требования. В отличие от HTTP, NNTP и FTP частично осуществляют сохранение

состояния (см. главу 5).

Решение не поддерживать сохранение состояния в HTTP было принято на ста-

дии разработки протокола с целью обеспечить его расширяемость. На момеггг по-

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

реализованы протоколы, не сохраняющие состояние. Также предполагалось осуще-

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

сурсов в Internet. Добавление сохранения состояния в HTTP создало бы помеху

для расширяемости Web. Протокол, требующий сохранения состояния между не-

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

ходимости храпения значительных объемов информации на сервере.

По мере развития Web отсутствие сохранения состояния в HTTP стало пред-

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

ной коммерции требуют сохранения состояния между HTTP-запросами. Транзак-

ция, состоящая из последовательности запросов и ответов, должна быть повторена

полностью, если один из запросов был прерван в ходе его выполнения. Управление

состоянием HTTP стало очевидной проблемой, что привело к появлению cookies

(см.

главу 2, раздел 2.6).

МЕТАДАННЫЕ РЕСУРСА

Метаданные

—

это информация, относящаяся к ресурсу, но не являющаяся ча-

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

188

Часть

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

Simple Mail Transfer Protocol (SMTP) [Pos82j, в котором имелась возможность оп-

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

в запрос, и в ответ HTTP. Примерами метаданных являются: размер ресурса; тип

содержания, например, text/html; время последней модификации ресурса и т.д.

В зависимости от конкретного ресурса в сообщение могут включаться различные

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

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

времени ожидания ответа. Для статических же ресурсов эта информация может

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

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

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

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

просов и ответов может быть обязательным.

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

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

• Знание информации о кодировании содержимого может облегчить ее обработку.

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

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

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

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

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

рел ресурс.

6.1.2, Влияние других протоколов

Как упоминалось в первой главе, несколько систем конкурировали с Web в пре-

доставлении доступа к ресурсам в Internet. На развитие протокола HTTP оказали

влияние конкурирующие системы, такие как Gopher и WAIS. В этом разделе мы

исследуем внешние влияния, оказанные на HTTP, и сравним HTTP с другими

протоколами прикладного уровня.

РОЛЬ MIME

Разработанный в 1992 г. стандарт Multipurpose Internet Mail Extensions (MIME)

стал расширением протокола Internet Mail Protocol (документ RFC 822), призван-

ным облегчить отправку нескольких объектов, как текстовых, так и нетекстовых,

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

мощью наборов ne-ASCII символов. MIME определяет объекты мультимедийных

данных и создает предпосылки для регистрации организацией Internet Assigned

Numbers Authority (lANA) новых форматов данных.

В июне 1992 г. было* высказано предложение [Соп92] добавить возможности

MIME в Web, WAIS и Gopher. В идеале представлялось, что все ресурсы могут

быть инкапсулированы с помощью MIME, а протоколы, такие как Gopher и HTTP,

будут работать только с MIME-совместимыми данными. Хотя эта идея не была

реализована, некоторые концепции MIME [BL92bJ оказались полезными для Web:

• Классификация форматов данных. Главной концепцией MIME, получившей

признание в Web, является формат данных

—

данные в различных форматах

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

собами. В HTTP формат данных определен как М1МЕ-тип. HTTP использует

преимущества механизма расширяемости MIME.

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

• Форматы для сообщений, состоящих из нескольких частей. Способность

MIME включать несколько элементарных объектов в одно тело сообщения

(этот тип MIME называется «multipart») был с некоторыми расширениями

принят в HTTP.

Другие концепции MIME не были приняты:

• Механизм «обогащенного текста (rich text)» для разметки текста MIME был

в чем-то схожим с языком разметки Standard Generic Markup Language

(SGML), от которого произошел HTML. Возможности представления инфор-

мации в HTML оказались такими же или даже лучшими.

• Способ обращения к внешним документам. Формат MIME для ссылок на до-

кументы мог быть синтаксически отображен па URI (хотя в тот момент они

назывались UDI (от Universal Document Identifier)).

Различия между MIME и HTTP можно обобщить следующим образом:

• MIME был предназначен для обмена сообщениями электронной почты. Глав-

ное назначение HTTP

—

обеспечить высокую производительность при любых

соединениях.

• Использование и интерпретация определенных полей заголовка в MIME и

в HTTP различаются. Например, в HTTP заголовок Content-Length исполь-

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

головка в запросе или ответе. В MIME соответствующее ноле заголовка явля-

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

которые не включаются в сообщение. Content-Length в MIME не является

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

сти включать это поле заголовка.

• В отличие от MIME, в HTTP нет ограничений на длину строки сообщения.

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

шую длину.

• HTTP не является совместимым с MIME. В MIME отсутствует понятие коди-

рования содержания, определенного в протоколах HTTP/LO и HTTP/LL За-

головок Content-Encoding в HTTP (см. раздел 6.2.3) содержит список моди-

фикаций представления ресурса. В HTTP не используется заголовок Con-

tent-Transfer-Encoding MIME.

• Понятие содержимого (entity) в MIME и в HTTP различается. MIME был

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

сообщение. В MIME существуют два типа данных: содержимое и сообщение.

При этом не делается различий между сообщениями, отправляемыми между

отправителем и получателем напрямую, или же через промежуточные звенья.

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

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

меняемыми к содержимому.

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

Web [BL] и зависимостью от регистрации MIME-типов организациями, такими

как International Corporation for Assigned Numbers and Names (ICANN). Наличие

централизованного официального хранилища требует, чтобы все реализации, ссы-

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

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

альтернативой.