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

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

210

Часть

III.

Web-протоколы

КЛАСС ОТВЕТОВ, СВЯЗАННЫЙ С ОШИБКАМИ КЛИЕНТА

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

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

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

нию ошибок. В НТТР/1.0 имеются следующие четыре кода ошибок клиента:

• 400 Bad Request. Этот ответ указывает, что синтаксис запроса был либо не-

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

• 401 Unauthorized. Если в запросе отсутствует необходимая информация о

правах доступа, сервер возвращает код ошибки 401 Unauthorized. Это может

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

полномочиях доступа, либо эта информация неверна. Вопросы, связанные

с аутентификацией в НТТР/1.0, рассматриваются в разделе 6.4.

• 403 Forbidden. Код ответа 403 Forbidden возвращается, если сервер не будет

принимать запрос. При этом запрос был понят сервером, но сервер умышлен-

но отказывается его обработать. Причина отказа может включаться сервером

в тело содержимого.

• 404 Not Found. Принимая во внимание большое количество запросов на несу-

ществующие ресурсы, следует признать наиболее широко распространенным

кодом ошибки клиента код 404 Not Found. Этот код возвращается, если ис-

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

обусловлена тем фактом, что ресурс временно недоступен. В НТТР/1.0 не

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

доступным.

КЛАСС ОТВЕТОВ, СВЯЗАННЫЙ С ОШИБКАМИ СЕРВЕРА

Класс кодов ответов 5хх используется для ошибок, связанных с сервером, или

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

мент. Отличие от класса кодов 4хх состоит в том, что ошибка имеет место на серве-

ре,

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

В классе 5хх имеются следующие четыре кода ответов:

• 500 Internal Server Error. Умалчиваемым для класса 5хх является код 500

Internal Server Error, который возвращается, если сервер не может точно оп-

ределить характер ошибки.

• 501 Not Implemented. Если сервер знает, что у него нет возможности работать

с определенным методом запроса, он может вернуть код 501 Not Implemented.

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

ней версии протокола, возвратит этот код.

• 502 Bad Gateway. Код ответа 502 Bad Gateway используется, если сервер,

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

тать ответ, полученный от другого сервера. Это указывает, что отвечающий

сервер не был источником ошибки.

• 503 Service Unavailable. Если сервер временно не может ответить, но надеется

ответить позднее, он использует код ответа 503 Service Unavailable. Сервер

может временно быть занят. Этот ответ указывает клиенту, что ему следует

попытаться повторить запрос позднее.

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

6.3.

Расширяемость HTTP

Одним из главных принципов при разработке HTTP была идея расширяемости.

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

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

ответов и коды ответов. Как мы увидим в главе 7, в НТТР/1.1 было добавлено не-

сколько новых методов, заголовков и кодов ответов. Ресурсы могут иметь любое

представление и тип содержания. Отсутствие ненужных ограничений в протоколе

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

на момент создания протокола. В качестве примера можно привести появление

в Web потокового мультимедиа (см. главу 12).

На первых порах существования Web популярностью пользовались несколько

браузеров, периодически появлялись их новые версии. Новые пользователи Web

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

которые являются зависимыми от браузера. Поскольку число пользователей в Web

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

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

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

мость со старыми версиями браузеров.

Расширяемость не означает, что протокол совершенен, или что реализации ком-

понентов не определяют некоторых ограничений. Принцип разделения ответст-

венности гласит, что протокол не должен принимать во внимание специфику своей

реализации. Реальность рынка диктует принципы эволюции протокола. В главе 7

мы рассмотрим, как протокол эволюционирует в соответствии с требованиями

практики.

6.4. SSL и безопасность

Проблема безопасности возникла с того момента, как компьютерные сети ста.аи

взаимодействовать друг с другом. Все больше информации доступно через Web, все

больше коммерческих организаций стало взаимодействовать через Web. Проблеме

безопасности в Web с самого начала было уделено серьезное внимание. Известной

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

Web-серверы стали достаточно сложными. Исходный код современных браузеров и

серверов включает в себя сотни тысяч строк. В типовой Web-транзакцни принимаю!

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

ков безопасного Web-взаимодействия невозможно достичь только защитой клиент-

ского и серверного приложений. Любое из промежуточных звеньев может изменить

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

Протокол HTTP/1.0 имеет свой собственный механизм безопасности. Однако

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

в обеспечении безопасности, па самом раннем этане предпринимались попытки

обеспечить безопасность Web-взаимодействий на более низком, чем прикладной,

уровне. Таков механизм протокола Secure Socket Layer, ставшего широко извест-

ным как SSL [SSL95J. В этом разделе мы обсудим SSL и его применение в связке

с HTTP. Мы также рассмотрим собственный механизм безопасности HTTP/1.0.

212

Часть

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

6.4.1.

SSL

SSL был разработан Netscape в 1994 г. и стал основой для стандарта IETF

Transport Layer Security (TLS) [DA98]. SSL

—

это протокол между транспортным и

11ри1счадным уровнями. Все протоколы прикладного уровня, такие как HTTP, LDAP и

Internet Message Access Protocol (ШАР [IMAJ), MOiyr использовать SSL. SSL вер-

сии 3.0 [SSLJ, который появился после выявления и устранения недостатков более

ранних версий, в настоящее время является текущей версией SSL и составляет основу

TLS.

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

Гчавная цель SSL

—

обеспечить для клиента, использующего TCP/IP в качестве

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

нимающему SSL. Безопасность определяется шифрованием данных, передаваемых

между аутентифицированными клиентом и сервером. Естественная форма сообще-

ния преобразуется путем шифрования в форму, которая может быть прочитана

только тем, кто способен осуществить расшифровку. Преобразование открытого

текста в зашифрованный текст (криптографическую версию текста, которую не-

возможно прочесть) выполняется с помощью алгоритма и ключа. Существует мно-

жество математических алгоритмов шифрования, обеспечивающих различную сте-

пень криптографической устойчивости (т.е. степени сложности для постороннего

лица извлечь открытый текст из зашифрованного). Чтобы осуществить шифрова-

iHie,

необходимо применить определенный алгоритм и выбрать ключ. Ключом час-

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

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

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

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

комбинации. Чрезвычайно сложный алгоритм с небольшим ключом, представлен-

ным дюжиной битов, требует рассмотрения 2^^ (т.е. 4096) значений, что легко мо-

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

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

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

Дл1ггельность процесса шифрования/дешифрования напрямую не зависит от дли-

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

вим, чем сложный алгоритм с коротким ключом.

Зашифровангюе сообщение, таким образом, может быть передано через сеть, кото-

рая является уязвимой для перехвата сообщения. Даже если по перехваченным фраг-

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

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

текст будет невозможно. Различные алгоритмы шифрования и их возможности не

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

титься к другим источникам, затрагивающим эту тему (например, [Ste98a, RGR97]).

Кринто1рафия па основе открытого к7поча и сертификатов используется серве-

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

бой файл, идентифицирующий личность или организацию. Клиент может убедиться,

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

фикат доверенной сторонней организации. Сервер, в свою очередь, может гарантиро-

вать тождество клиента, проверив клиентский сертификат. На практике сервер ред-

ко н])оверяет клиентский сертификат. И клиеггг, и сервер могут иметь небольшой

список таких доверенных сторонних организаций, выдающих сертификаты.

Протокол SSL состоит из двух составных частей: установления SSL-соединения

и защищенного взаимодействия. Протокол установления SSL-соединения схож

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

с соответству10ЩР1м протоколом, используемым в TCP. На фазе установления

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

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

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

которое осуществляет необходимые шрхфрование, сжатие и реорганизацию данных.

Главным назначением защищегнюго взаимодействия является гарантия для обеих

участвующих в обмене сторон, что данные будут зашифрованы при сохранении це-

лостности сообщения. Протокол защищенного взаимодействия разбивает инфор-

мацию на фрагменты размером не более 16 Кб, при необходимости осуществляя

сжатие перед вычислительными операциями по проверке целостности, выполняет

шифрование результата и отправляет его вместе с заголовком. При получении со-

общения с Web-сервера действия вьнюлняются в обратном порядке: проверка це-

лостности, декомпрессия (необязательно) и доставка, скажем, браузеру.

Отметим, что протокол защищенного взаимодействия никоим образом не свя-

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

тификата осуществляется независимо от аутентификации НТТР/1.1.

Первым шагом в коммуникационном взаимодействии с использованием SSL яв-

ляется выбор метода шифрования. Не все методы шифрования одинаково стойкие,

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

ют все методы. Таким образом, клиент и сервер сначала выбирают максимально

стойкий метод, поддерживаемый обеими сторонами. Практически все клиенты и

серверы SSL используют аутентификацию на основе сертификатов, поэтому сервер

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

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

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

ствляют авторизацию пользователя на основе предоставленной им информации о

кредитной карте. Сайт электронной коммерции обычно взаимодействует со сто-

ронней компанией (банком-эмитентом кредитной карты), действующей в качестве

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

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

у клиента сертификат. Например, сайт, который хочет максимально обезопасить

себя, может настоять на проверке сертификата клиента.

Далее клиент и сервер обмениваются сообщениями, схожими с сообщениями

SYN, используемыми в TCP, после чего они готовы начать обмен информационны-

ми сообщениями. С целью снизить риск компрометации обменов они также обмени-

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

момента начинается передача потока данных, зашифрованного с помощью выбран-

ного метода шифрования.

Вопросы, связанные со стойкостью протокола шифрования и органами серти-

фикации, находятся вне сферы рассмотрения этой книги. Читателям можно посо-

ветовать обратиться к другим книгам (например, [Ste98a]), посвященным пробле-

мам безопасности в Web.

6.4.2 HTTPS. Использование SSL при обмене

данными в Web

HTTPS — это протокол, который использует SSL для передачи HTTP-сообще-

ний. Вся информация в коммуникационном взаимодействии между клиентом и

сервером зашифровывается, включая и URL запроса. Сетевые анализаторы, пере-

хватывающие передаваемый трафик, не смогут определить, к какому ресурсу осу-

214

Часть

111.

Web-протоколы

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

Таким образом, запросы защищены от нарушения безопасности и постороннего

вмешательства. В отличие от HTTP, в котором обычно используется порт 80 TCP,

в HTTPS чаще всего используется порт 443. Необходимость отдельного порта обу-

словлена наличием выделенного сокета TCP/IP для обмена HTTPS-сообщениями.

Наиболее часто SSL используется совместно с HTTP, хотя могут применяться и

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

браузер использует SSL. Главные отличия состоят в том, что URL начинаются с https:

вместо http:, а если процедура установления SSL-соединеиия заканчивается неудачно,

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

Следует отметить, что хотя HTTP является протоколом, не сохраняющим со-

стояния, и HTTP-соединение может быть закрыто путем закрытия ТСР-соедине-

ния, относящаяся к SSL информация может быть сохранена и повторно использо-

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

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

к другому ресурсу на том же сайте. Новый сеанс SSL при этом устанавливать не

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

Многие версии популярных клиентских браузеров, таких как Netscape и Internet

Explorer, а также многие популярные Web-серверы поддерживают SSL. Браузеры

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

колов (например, SSL 2.0 или SSL 3.0). После выбора версии протокола возможна

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

Netscape предоставляет несколько вариантов выбора метода шифрования для

SSL 3.0, включая стандарт Data Encryption Standard (DES), принятый Националь-

ным институтом стандартизации США (NIST), и ряд методов, разработанных фир-

мой RSA Company [RSA], таких как RC2 и RC4.

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

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

осознанно они смогут сделать выбор метода шифрования. В связи с этим настрой-

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

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

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

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

срок действия сертификатов.

Обычно браузеры отображают значок (закрытый замок), если соединение ис-

пользует SSL.

6.4.3. Безопасность в НТТР/1.0

Поскольку не все транзакции используют SSL, в НТТР/1.0 предусмотрен собст-

венный механизм безопасности. Соглашения по безопасности в НТТР/1.0 главным

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

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

целенными на пути ресурсов в виртуальной файловой системе сайта с целью дос-

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

с сайта. Например, хотя на Web-странице сайта может иметься гиперссылка па

URL http://www.1729.org/unitl/fl, пользователь может попытаться осуществить

доступ по URL http://www.1729.org/unitl/f2. Если такой URL существует, внеш-

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

сайта www.1729.org мог не предусмотреть такой возможности. Подобные попытки

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

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

1Юобразно, и многие пользователи применяют схожие пути в файловой системе

для взаимосвязанных URL. Также имеются более изощренные возможности пред-

положить наличие URL, которые официально недоступны извне. Многие пользо-

ватели полагают, что для доступа но URL должна существовать хотя бы одна ги-

перссылка на Web-странице. Конечно, можно требовать ауте1пификации для каж-

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

Спецификация протокола учитывает возможность неподобающего ис1юльзова-

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

этом говорится в главе 9), что создает условия для вторжения в личную жизнь поль-

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

пий и т.д. Заголовки Referer и From (см. раздел 6.2.3) являются примерами заголов-

ков,

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

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

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

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

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

гать такого нарушения их безопасности.

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

пользованием CGl-сцепариев (глава 4, раздел 4.2.3). CGI служит в качестве основ-

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

ные проблемы, связанные с безопасностью. К таким проблемам относятся побоч-

ные эффекты при вызове сценариев, например, злонамеренные пользователи могут

указать параметры, которые приведут к переполнению буфера.

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

не приводит к возникновению каких-либо побочных эффектов на исходном серве-

ре.

На нервом месте по безопасности идут методы GET и HEAD. Однако вполне

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

ре (например, CGI-сценарий), приведет к созданию, модификации или удалению

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

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

ных методов, которые могут вызвать побочные эффекты.

Аутентификация клиента в НТТР/1.0 основывается на типовой схеме вызов-от-

вет, известной как схема простой (basic) аутентификации. Клиенту, желающему

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

WWW-Authenticate). Клиент должен ответить корректным набором полномочий,

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

в заголовке Authorization, и, если они принимаются сервером, посылается ответ.

Однако если полномочия не принимаются, сервер обычно передает ответ 403

Forbidden или 401 Unauthorized. К несчастью, в НТТР/1.0 полномочия передают-

ся открытым текстом, что делает их незащищенными.

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

НТТР/1.0, была сформирована отдельная группа по проблемам безопасности

[HTT94J. Хотя нельзя сказать, что безопасность вообще не была учтена в НТТР/1.0,

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

Как мы увидим в следующей главе, частично это было исправлено в НТТР/1.1.

216

Часть

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

6.5 Совместимость и взаимодействие

протоколов

Протокол 01Н1сывает синтаксис и семантику коммуникационного взаимодейст-

вия между двумя или более участниками. Правила, ассоциированные с различны-

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

также коды ответов, ожидаемые в качестве отклика, являются частью специфика-

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

протокола. Компонент с определенной версией протокола (например, НТТР/1.0)

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

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

ты должны сохранять обратную совместимость.

Требование совместимости к протоколу может быть простым, например, чтобы

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

то синтаксическим требованием. Однако требования могут быть и более сложными:

сервер, обслуживающий несколько организаций, не доверяющих друг другу, должен

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

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

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

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

держал данные, идентифицирующие пользователя или агента пользователя.

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

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

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

считающихся стандартами. Например, RFC 1945, описывающий НТТР/1.0, является

информационным документом, и в связи с этим не содержит требований к совмести-

мости. RFC 2616, описывающий НТТР/1.1, является проектом стандарта. О принци-

пах совместимости для протокола НТТР/1.1 мы поговорим в главе 15 (раздел 15.3).

6.5.1.

Номер версии и совместимость

Когда НТТР-компопепты взаимодействуют друг с другом, помер версии в сооб-

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

быть способен интерпретировать все сообщения, имеющие номер версии, меньший

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

ют как синтаксис (формат сообщений), так и семантику (возможности и особенно-

сти этой версии протокола). Ответ сервера должен быть представлен в версии про-

токола, которая понятна для клиента. HTTP-клиент должен правильно указать

собственный помер версии и интерпретировать сообщения с сервера в формате

версии, равной или меньшей, чем его собственная.

Номер версии HTTP состоит из старшей и младшей части. Например, в НТТР/1.0

старшей частью является 1, а младшей частью

—

0. Правила для старшей и младшей

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

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

лиза сообщений остался неизменным. Младший номер может быть изменен (измене-

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

менения старшего номера. Однако если требуется изменение формата сообщения, то

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

влияет па совместимость.

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

Детали интерпретации номера версии поясняются в документе RFC 2145

[MFGF97J. Требования к надежности коммуникационного взаимодействия требу-

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

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

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

6.5.2. Уровни требований MUST (обязательный),

SHOULD (желательный) и MAY (возможный)

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

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

дания уровней требований был формализован в документе RFC 2119 [ВгаЭба].

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

колов Internet. Имеется три уровня требований: MUST (обязательный), SHOULD

(желательный) и MAY (возможный). Имеются также отрицательные требования

MUST NOT (не должен) и SHOULD NOT (нежелательно).

Уровни требований к совместимости являются важной составной частью специ-

фикации любого протокола. Без них возможно появление произвольных реализа-

ций, не способных взаимодействовать друг с другом. Разработчики компонентов,

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

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

необязательными. Деление на различные уровни по совместимости упрощает зада-

чу разработчикам, поскольку они могут сосредоточиться на реализации только тех

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

Обязательный уровень требований (MUST) означает, что совместимость абсо-

лютно необходима. Реализация протокола, не обладающая этой характеристикой, не

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

MUST не соблюдается, реализация не является совместимой. Требование уровня

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

мой со спецификацией, если она не содержит данную функцию. Однако рекоменда-

ция подразумевает, что функция по возможности должна быть реа;н1зована. Реали-

зация, удовлетворяющая всем требованиям уровней MUST и SHOULD, считается

безусловно совместимой.

Требования уровня MAY являюлся дополнительными, и хотя подобные функции

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

тельным. Реа/тзация, отвечающая требованиям уровней MUST и SHOULD, будет

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

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

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

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

ми,

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

ям уровней MUST и SHOULD. Отсутствие совместимости со стороны одного ком-

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

поскольку это может привести к некорректной интерпретации результата другими

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

MUST и генерирует некорректный ответ. Расположенный на пути сооби1ения про-

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

его.

Некорректный ответ будет переправлен как верный ответ многим клиентам,

которые запросят этот же ресурс в дальнейшем.

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

Имеется несколько общих правил совместимости для клиентов и серверов

HTTP, носылаюпщх номера версий. Например, HTTP-сервер не должен (MUST

NOT) отправлять помер версии, для которой не имеет места по меньшей мере ус-

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

клиенте, он может (MAY) отправить меньший номер версии. Точно так же, если

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

может (MAY) отправить меньший помер версии.

6.6. Резюме

Хотя текущей версией HTTP является версия НТТР/1.1 (она будет рассмотрена

в следуюп^ей главе), полезно начать изучение эволюции протокола HTTP с первых

дней возникновения World Wide Web. Что еще более важно, имеется ряд клиентов,

серверов-посредников и Web-серверов, которые все еще Р1спользуют НТТР/1.0. Зна-

чительная часть трафика в Web приходится па НТТР/1.0. По-прежнему еще созда-

ются встроен1няе клиенты НТТР/1.0. Некоторые решения при разработке НТТР/1.0

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

не 80-х и в начале 90-х годов прошлого века. Введение гипертекстовых ссылок спо-

собствовало взрывному росту Web и массовому применению протокола HTTP. Сис-

гематизация имеющихся методов, заголовков и кодов ответов помогает Web-компо-

iieinaM без проблем взаимодействовать друг с другом.

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

ции клиентов, серверов-посредников и Web-серверов, использующих НТТР/1.0,

было извлечено много уроков. К счастью, ключевые идеи, такие как классы кодов

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

жать ряда проблем. Решение сделать HTTP протоколом без сохранения состояния

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

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

в этой KHiH^e.

Применение НТТР/1.0 на практике привело к ряду усовершенствований, от дол-

говременных соединений до безопасности. Эти усовершенствования стали иобуди-

тельной причиной появления НТТР/1.1. Хотя некоторые популярные Web-браузе-

ры и многие Web-серверы, поддерживающие функционирование популярных Web-

сайтов, перешли на НТТР/1.1, версия НТТР/1.0 по-прежнему широко используется.

HTTP/1.1

в предыдущей главе мы рассмотрели происхождение и начальный этап эволю-

ции протокола HTTP, приведший к появлению версии, известной как НТТР/1.0.

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

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

незначительных изменений до выхода официального стандарта, мы не думаем, что

вероятны сколько-нибудь существенные изменения. Основными источниками ин-

формации, на которых основана эта глава, являются RFC 2616 [FGM^99],

RFC 2617 [FHBH^99] и архив, включающий тысячи сообщений электронной поч-

ты списка рассылки HTTP Working Group [WG-99] с сентября 1994 до момента

публикации данной книги.

Эта глава начинается с обзора эволюции протокола НТТР/1.1. Проблемы, свя-

занные с НТТР/1.0, и промежуточные нестандартные реализации привели к тому,

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

связанные с НТТР/1.0, и сопоставим их с основными семантическими изменения-

ми в НТТР/1.1, представленными в остальной части главы. Перечисление синтак-

сических отличий между НТТР/1.0 и НТТР/1.1, сгруппированных но методам, за-

головкам и кодам ответов, необходимо для понимания семантических отличий. За-

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

совместно с целями внесения этих изменений. Для большей ясности изложения

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

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

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

компонентов, соответствующих НТТР/1.1. Завершается глава описанием роли

прокси-серверов, которые должны удовлетворять требованиям НТТР/1.1, предъяв-

ляемым как со стороны клиентов, так и серверов.

7.1.

Эволюция протокола НТТР/1.1

к тому времени, когда с целью зафиксировать актуальную для того времени

практику применения НТТР/1.0 был опубликован документ RFC 1945, уже суще-

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

ваемых через Internet гипертекстовых данных. HTTP уже стал основным протоко-

лом Internet по числу передаваемых пакетов и байтов. Повсеместное преобладание

Web-документов со встроенной графикой привело к увеличению пользовательско-

го трафика. Доля текста в общем объеме передаваемых данных стремительно сни-

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

больших картинок в формате Graphics Interchange Format (GIF), таких как кнопки

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