Обзор HTTP

удобно осуществлять в историческом контексте. HTTP эволюционировал вместе со Всемирной паутиной и ее двумя другими компонентами: URI и HTML. В процессе эволюции HTTP можио выделить два этана:

•          от появления первой спецификации НТТР/0.9 до версии НТТР/1.0 (этот период занял четыре года);

•    от появления НТТР/1.0 до появления НТТР/1.1 (еще четыре года).

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

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

Дата

Документ

Январь 1997 г.

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

Июнь 1999 г.

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

2001 г.

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

HTTP был предложен в марте 1990 г. Тимом Бериерс-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Internet и облегчения навигации посредством гиперссылок [Nel67J. Самая ранняя версия протокола HTTP/0.9′ была впервые опубликована в январе 1992 г. в списке рассылки www-talk [BL92a), хотя его реализация датируется 1990 годом. Спецификация НТТР/0.9 привела к упорядочению правил взаимодействия между клиентами и серверами, а также разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения, а НТТР/0.9 получил статус подмножества более детализироваииого протокола, разработка которого планировалась в то время. Основное внимание тогда было сосредоточено на поисковых возможностях, поскольку поиск был главной функцией, предоставляемой конкурирующими системами, такими как Gopher и Archie.

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

В декабре 1992 г. в списке рассылки www-talk завязалась дискуссия о возможности использования MIME в глобальных информационно-поисковых системах, таких как Wide Area Information Servers (WAIS) и Web. Развивавшийся в то время стандарт Internet MIME упорядочивал форматы данных и обеспечивал пересылку сообщений, состоящих из нескольких разнородных частей по электронной почте. НТТР-ответы могли возвращаться в виде MIME-сообщений. Первая предварительная спецификация НТТР/1.0 появилась в марте 1993 г. В июне 1993 г. в проекте спецификации [BLC93J было предложено сделать HTML одним из типов содержимого MIME. Позже, в октябре 1993 г., после дискуссии в рабочей группе URI была опубликована первая предварительная спецификация унифицированных указателей ресурсов (URL — Uniform Resource Locators) [BL93bJ.

После этого вышло несколько рабочих проектов документов НТТР/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. Официальный стандарт2 HTTP должен появиться в 2001 г.

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

•          Свойства протокола. Здесь рассматриваются взаимосвязь HTTP с инфраструктурой URI, система функционирования HTTP по принципу запрос-от- вет, отсутствие сохранения информации о состоянии между запросами и понятие метаданных (информация о ресурсе).

•          Влияние других протоколов. Здесь рассматривается влияние стандарта MIME на HTTP, а также некоторых других протоколов, популярных на момент разработки HTTP. Мы также сравним HTTP с другими протоколами прикладного уровня.

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

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

•          Глобальные URI. HTTP основывается на механизме именования URI. HTTP использует URI во всех транзакциях для идентификации ресурсов в Web.

•          Обмен по схеме запрос-ответ. HTTP-запросы отправляются клиентами, получая затем ответы от серверов. Направление потока — от клиента к серверу; сервер не инициирует Web-трафик.

•          Отсутствие сохранения состояния. Состояние между запросами и ответами клиентами и серверами не сохраняется. Каждая riapa запрос-ответ трактуется как независимый обмен сообщениями.

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

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

HTTP основывается на идее унифицированного идентификатора ресурса (URI — Uniform Resource Identifier) [BLFM98]. Механизм именования дает возможность размещать ресурсы в любой точке Internet и разделить понятия ресурса и ответа. Ресурс может иметь связанный с ним URI, хотя представление ресурса и его информационное содержание может многократно меняться за время существования ресурса. С точки зрения протокола URI представляет собой форматированную строку. URI просто указывает на ресурс вне зависимости от его текущего местоположения или имени, по которому он известен. В этом смысле URI является комбинацией унифицированного указателя ресурса (URL — Uniforrn Resource Locator) [BLMM94, Fie95] и унифицированного имени ресурса (URN — Uniform Resource Name) [SM94]. URI представляет собой надмножество URL, URN и может быть выражен одной из этих составляющих, либо обеими. Наиболее популярной формой URI является URL.

В качестве примера, поясняющего различия между URI, URL и URN, возьмем эту книгу. Американское издание книги имеет ISBN 0-201-71088-9, присвоенный Библиотекой Конгресса США. Номер ISBN гарантированно уникален, отличается от всех номеров уже опубликованных книг и останется неизменным даже после публикации миллиона других книг. Только Библиотека Конгресса США решает, как присвоить уникальный номер этой книге. Номер ISBN представляет собой URN для этой статьи; оп именует книгу, но не предоставляет информацию о том, где книга может быть получена. URI для этой книги может представлять ее содержание, если все содержание доступно через компьютерный протокол. Предположим, что содержание этой книги было помещено на 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/bala/kandr.ps.gz. Этот URL задает местонахождение копии ресурса. Таким образом, URI статьи может быть представлен любым из упомянутых выше URL или URN (номером ISBN).

URI считается абсолютным, если строка начинается со схемы, за которой следует строка, представляющая ресурс, который может быть получен через схему. Схема просто указывает протокол, который будет использоваться для доступа к ресурсу. Относительный URI не начинается с имени схемы. В самой первой спецификации протокола HTTP, известной позднее как HTTP/0.9 [BL92a], было перечислено пять схем: file, news, http, telnet, gopher. Он также предвосхитил использование по меньшей мере еще двух (WAIS и X-500) и зарезервировал схемы для пих.

Хотя имя схемы связано с определенным протоколом, для доступа к ресурсу по URL может быть задействовано более одного протокола. Для обработки Web-запроса на ресурс обычно требуется несколько протоколов, таких как Domain Name System (DNS) для определения IP-адреса хоста, на котором размещен ресурс, по его доменному имени, и Transmission Control Protocol (TCP) для загрузки ресурса по соединению транспортного уровня. Точно так же для идентификации одного ресурса может быть использовано более одной схемы.

Наиболее часто в Web используется схема http. Каждая схема имеет свой собственный синтаксис, и для всех схем предусмотрены механизмы для именования ресурсов. За счет отделения схемы от внутреннего синтаксиса конкретного протокола механизм именования в Web дает возможность легко адаптировать себя для других систем. Поскольку доступ к одному и тому же ресурсу может быть осуществлен с использованием различных протоколов, другие системы могут быть наложены поверх HTTP. Возможность использовать не-НТТР URI, т.е. работать с ресурсами, доступ к которым осуществляется через протоколы, отличные от HTTP, была необходима, поскольку подобная практика была вполне типичной на момент создания Web. Отделение схемы от синтаксиса привело к тому, что Web превратилась во внешний интерфейс для доступа к ресурсам, для работы с которыми обычно используются другие протоколы, например, ftp. В качестве примеров пе-НТТР URI можно привести rtsp://clips.foo.com/preview/audio, telnet://ox.aciri.org и т.д. Столкнувшись с не-НТТР URI, браузер осуществляет синтаксический Анализ имени схемы до символа ":" и активизирует соответствующий обработчик протокола — RTSP (Real Time Streaming Protocol) и Telnet, соответственно.

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

Протокол HTTP задает синтаксис и семантику, в соответствии с которыми компоненты Web, такие как клиенты и серверы, взаимодействуют друг с другом. HTTP-сообщение структурировано и обладает определенным синтаксисом. HTTP является запрос-ответным протоколом, в котором запрос — это сообщение, посылаемое клиентом принимающему серверу. Принимающим может быть исходный сервер — сервер, на котором размещаются или генерируются ресурсы, или промежуточное звено, гакое как прокси-сервер. Сервер-получатель отправляет обратно сообщение-ответ. Клиентом может выступать агент пользователя, нечто, инициировавшее запрос, или какой-либо компонент на пути между инициатором и конечным сервером-нолучателем. Протокол определяет набор расширяемых методов запроса, которые используются клиентом для выполнения операций, таких как иолу- чепие, изменение, создание или удаление ресурса. Ресурсом является объект, сервис или коллекция элементарных сущностей, которые могут быть четко идентифицированы и размещены в любом месте сети [BLFM98J.

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

GET /foo.html НТТР/1.0

Строка /foo.html идентифицирует запрашиваемый с помощью метода GET ресурс. Номер версии протокола HTTP, в данном случае 1.0, используется для идентификации возможностей отправителя. Цель запроса — получить текущее содержимое ресурса, идентифицируемого строкой /foo.html, с сервера. Если быть более точным, запрос приводит к применению метода GET к ресурсу, идентифицируемому /foo.html. В общем случае сообщение-запрос состоит из метода, URI, идентификатора версии протокола, необязательных нолей заголовка запроса и необязательных данных, отправляемых с запросом.

После получения сообщения-запроса сервер осуществляет его синтаксический Анализ и применяет метод к ресурсу. Сформированный ответ передается обратно клиенту в качестве сообщения-ответа. Например,

НТТР/1.0 200 0K

Date: Wed, 22 Mar 2000 08:01:01 GMT

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

Content-Length: 3913

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

Сообщение-ответ состоит из числового кода ответа (например, указывающего на успех или неудачу), фразы, поясняющей числовой код ответа, необязательных полей заголовка и необязательного тела сообщения. В примере первая строка, известная как строка состояния, содержит помер версии HTTP и код ответа 200 OK, указывающий, что запрос выполнен успешно. Заголовок ответа 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 используют в качестве протокола транспортного уровня протокол Transmission Control Protocol (TCP).

Сервер не может ответить до того, как будет получен запрос. Направление обмена сообщениями от клиента к серверу, а затем от сервера к клиенту. НТТР-сервер может не отвечать на запрос. В этом смысле HTTP схож с другими протоколами прикладного уровня, такими как Gopher [AAL+92J и WAIS [KM91J.

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

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

HTTP представляет собой протокол, не сохраняющий своего состояния (stateless). Это означает отсутствие сохранения промежуточного состояния между парами запрос-ответ. Каждый новый запрос на ресурс инициирует отдельное применение метода запроса к URI ресурса и создание нового ответа. Компоненты, использующие HTTP, могут и осуществляют сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий несколько запросов подряд, может отслеживать задержки ответов. Сервер может хранить информацию об IP-адресе клиента, отправившего последние десять запросов. Однако сам протокол не осведомлен о предыдущих запросах и ответах. В протоколе не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования. В отличие от HTTP, NNTP и FTP частично осуществляют сохранение состояния (см. главу 5).

Решение не поддерживать сохранение состояния в HTTP было принято на стадии разработки протокола с целью обеспечить его расширяемость. На момент появления Web существовало пескоЛько конкурирующих систем, в которых были реализованы протоколы, не сохраняющие состояние. Также предполагалось осуществить поддержку использования конкурирующих систем для доступа к ряду ресурсов в Internet. Добавление сохранения состояния в HTTP создало бы иомеху для расширяемости Web. Протокол, требующий сохранения состояния между несколькими, не связанными друг с другом соединениями, также привел бы к необходимости храпения значительных объемов информации на сервере.

По мере развития Web отсутствие сохранения состояния в HTTP стало представлять проблему для некоторых приложений. Например, приложения электронной коммерции требуют сохранения состояния между HTTP-запросами. Транзакция, состоящая из последовательности запросов и ответов, должна быть повторена полностью, если один из запросов был прерван в ходе его выполнения. Управление состоянием HTTP стало очевидной проблемой, что привело к появлению cookies (см. главу 2, раздел 2.6).

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

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

Simple Mail Transfer Protocol (SMTP) [Pos82J, в котором имелась возможность определения характеристик полезной нагрузки. Метаданные могут быть включены и в запрос, и в ответ HTTP. Примерами метаданных являются: размер ресурса; тип содержания, например, text/html; время последней модификации ресурса и т.д. В зависимости от конкретного ресурса в сообщение могут включаться различные метаданные. Например, для динамически генерируемых ответов длину содержимого включать нежелательно, поскольку определение длины приведет к увеличению времени ожидания ответа. Для статических же ресурсов эта информация может быть легко получена. Точно так же включать время последней модификации имеет смысл для статического ресурса, но не для динамического ресурса. Метаданные ресурса возвращаются в ответе с помощью ряда заголовков, которые будут рассмотрены далее в этой главе. Присутствие некоторых метаданных для определенных запросов и ответов может быть обязательным.

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

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

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

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

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

Как упоминалось в первой главе, несколько систем конкурировали с 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 (IANA) новых форматов данных.

В июне 1992 г. было высказано предложение [Con92] добавить возможности MIME в Web, WAIS и Gopher. В идеале представлялось, что все ресурсы могут быть инкапсулированы с помощью MIME, а протоколы, такие как Gopher и HTTP, будут работать только с MIME-совместимыми данными. Хотя эта идея не была реализована, некоторые концепции MIME [BL92bJ оказались полезными для Web:

•          Классификация форматов данных. Главной концепцией MIME, получившей признание в Web, является формат данных — данные в различных форматах могут пересылаться между отправителями и получателями различными способами. В HTTP формат данных определен как MIME-тин. HTTP использует преимущества механизма расширяемости MlME.

•          Форматы для сообщений, состоящих из нескольких частей. Способность 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 отсутствует понятие кодирования содержания, определенного в протоколах НТТР/1.0 и НТТР/1.1. Заголовок Content-Encoding в HTTP (см. раздел 6.2.3) содержит список модификаций представления ресурса. В HTTP не используется заголовок Content-Transfer-Encoding MIME.

•          Понятие содержимого (entity) в MIME и в HTTP различается. MIME был предназначен для почтовых сообщений, и содержимое включалась в почтовое сообщение. В MIME существуют два типа данных: содержимое и сообщение. При этом не делается различий между сообщениями, отправляемыми между отправителем и получателем напрямую, или же через промежуточные звенья. Первоначально делались попытки адаптировать для HTTP модель содержимого MIME, Однако при этом возникли трудности с преобразованиями, применяемыми к содержимому.

Определенное несоответствие имеется и между заявленной универсальностью Web [BL] и зависимостью от регистрации MIME-типов организациями, такими как International Corporation for Assigned Numbers and Names (ICANN). Наличие централизованного официального хранилища требует, чтобы все реализации, ссылающиеся на типы, были согласованными. Создание онлайнового реестра, который может быть доступен через сеть, для добавления нового тина считается наилучшей альтернативой.

Введение терминологии MIME затруднило разделение ролей полей заголовка, используемых в различных коптекстах, например, при передаче от клиента к серверу или паоборот. Набор полей HTTP-заголовка стал трактоваться, как произвольный набор строк ASClI, который может игнорироваться Web-компонентами, если последние их не понимают. HTTP-заголовки, как мы увидим в разделе 6.2.3 и в главе 7 (раздел 7.2.2), используются как для предоставления метаданных, так и для модификации поведения и интерпретации методов HTTP.

HTTP И ПРОТОКОЛЫ ARCHIE, GOPHER И WAIS

На разработку HTTP оказали влияние протоколы, которые были популярны во время создания Web. В главе 1 (раздел 1.1.1) обсуждалась роль, которую сыграли системы Archie, Gopher и WAIS в эволюции Web в целом. Различные аспекты, относящиеся к протоколам таких систем, иовЛияли на принципы, положенные в основу HTTP. В частности, в Gopher [AML+93] имелся протокол клиент-сервер, не сохраняющий состояние и схожий с тем, который был реализован в HTTP. Все серверы используют фиксированные ТСР-порты: 70 в Gopher, 210 в WAIS и 80 в HTTP. Идея типа документа в зачаТочном состоянии использовалась в Gopher. В HTTP понятие типа содержания было значительно расширено.

Протокол Prospero [NA93], который создал условия для единообразного обращения к множеству файлов в Internet, был применен в Archie. Prospero отличался главным образом своей раснределенной файловой системой, которая давала возможность пользователям создавать собственные представления наборов файлов, расположенных в любой точке Internet. Prospero был достаточно простым в смысле разделения доступа к данным и интерпретации данных. Однако оп не имел специального протокола для извлечения файлов, для этого в системе использовались другие протоколы, такие как FTP и Gopher. Сам Prospero использовал протокол UDP и дополнительный уровень для обеспечения надежности передачи данных поверх UDP. В противоположность этому, HTTP, Gopher и WAIS обычно используют TCP. В Prospero, в отличие от Gopher, не предусмотрены различпые уровни аутентификации. В последних версиях АгсЫе’плапировалось использовать URI.

Главным назначением протокола Gopher было удаленная выборка документов. Основным различием между Gopher и HTTP является использование гипертекста в HTTP, в Gopher использовались текстовые файлы и меню. HTTP трактует меню и текстовые файлы как особый вид гипертекста [BL92a]. Было бы неправильно сравнивать Gopher с более поздними версиями HTTP, поскольку протокол Gopher не был подвержен значительным усовершенствованиям с того времени, как Web стала доминировать. Хотя использование виртуальных каталогов давало возможность клиентам Gopher кэшировать последние извлеченные ресурсы, в протоколе Gopher отсутствовал какой-либо механизм для идентификации несоответствий между кэшированными элементами и текущим содержанием. Кэширование выполнялось на уровне приложений, вне протокола Gopher. Протокол Gopher был специально разработан, чтобы воспользоваться интеллектуальными возможностями серверов, а не реализовывать их в протоколе. Необходимость предоставления более широкого набора сервисов требовало усовершенствования сервера без внесения изменений в протокол. Хотя при этом протокол является гораздо более простым, чем HTTP, различные реализации серверов могут вести себя по-разному. Gopher определяет набор символов, указывающих, является ли ресурс, к которому осуществляется доступ, текстовым файлом, каталогом, двоичным файлом и т.д. Выбор одного символа для идентификации тина ресурса естественно ограничивает количество различных типов, которые могут быть представлены. HTTP в дальнейшем перешел к расширенному набору MIME-типов, а различные программные компоненты HTTP получили возможность воспринимать произвольные типы ресурсов. В протоколе Gopher не затрагиваются вопросы безопасности.

HTTP И ДРУГИЕ ПРОТОКОЛЫ ПРИКЛАДНОГО УРОВНЯ

На HTTP оказали влияние другие протоколы прикладного уровня, которые предшествовали Archie, Gopher и WAIS. Сам HTTP тоже повлиял на протоколы прикладного уровня. Ниже мы рассмотрим 110 одному примеру каждого из таких взаимовлияний.

HTTP перенял идею классов ответов (раздел 6.2.4) от протокола прикладного уровня SMTP [Pos82]. Вместо того чтобы попытаться изобрести новую схему для классификации различных ответов, была использована концепция функциональной Группы кодов ответов SMTP. Функциональная группа классифицировала ответы на небольшое число категорий, таких как успех, неудача или ошибка. По мере развития HTTP список классов расширялся, но базовая схема осталась неизменной.

HTTP представляет собой только один из протоколов прикладного уровня, наиболее популярный на текущий момент. Существуют другие протоколы прикладного уровня, которые переняли синтаксис и часть семантики HTTP, например, Real Time Streaming Protocol (RTSP) [SRL98], о котором пойдет речь в главе 12 (раздел 12.4).

Источник: 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