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

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

280

Часть

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

• Письмо должно быть получено В в целости и сохранности (то есть содержа-

ние,

отправленное А, не должно быть изменено).

Все это относится и к HTTP-сообщениям.

Используется несколько схем аутентификации. Для доступа к некоторым ре-

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

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

текстом. Для другР1х ресурсов могут требоваться более сложные процедуры аутен-

тификации, в которых шифруется пароль.

Одним из pacnpocTpaneiHibix методов аутентификации является схема за-

прос-ответ, в которой сервер посылает запрос и ждет специфического ответа кли-

ента. Запрос может иметь силу только для конкретной области (realm) — подмно-

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

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

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

UR1.

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

торизации. Преимущество защищенных пространств заключается в том, что к раз-

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

Мы начнем с обсуждения проблем модели обеспечения безопасности HTTP/1.0

и усилий, предпринятых для их преодоления в НТТР/1.1. Затем мы рассмотрим

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

шением, принятым в НТТР/1.1, было введение аутентификационной информации,

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

7.10.1.

Обеспечение безопасности и аутентификация

Обеспечение безопасности становилось ключевой проблемой по мере того, как

росла популярность Web и развивалась электронная коммерция. В НТТР/1.0 обес-

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

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

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

обычной (basic) аутентификации, описанный в главе 6 (раздел 6.4).

Схема обычной аутентификации в НТТР/1.0 была не слишком защищенной,

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

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

проекта спецификации НТТР/1.0. НТТР/1.0 не препятствовал использованию

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

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

лись закодированными с помощью base64 [FB96a]. Кодирование base64 практиче-

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

объектом перехвата. Развитие электронной коммерции привело к передаче через

Web номеров кредитных карт, которые и становятся целью перехвата.

Еще одной проблемой в НТТР/1.0 является отсутствие областей действия ау-

тентификации. В отличие от обычной аутентификации, аутентификация с помо-

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

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

трольных сумм. Срок действия полномочий в НТТР/1.0 был больше, чем нужно.

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

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

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

шенствованием механизма безопасности. Это было реализовано в НТТР/1.1 путем

Глава 7. HTTP/1.1 281

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

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

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

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

метки. Временная метка является кодом по модулю 16 или по модулю 64, которая

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

ответ 401 Unauthorized (ответ 401 Unauthorized посылается тогда, когда сервер

считает, что полномочия клиента являются недостаточными). Значение временной

метки создается на основе комбинации времени, генерируемого сервером, атрибута

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

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

Аутентификация в HTTP подробно обсуждается в документе RFC 2617, кото-

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

7.10.2. Целостность

Целостность сообщения — это важная составная часть обеспечения безопасно-

сти:

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

хранности. Новый заголовок содержимого Content-MD5 в НТТР/1.1 используется

для проверки целостности тела содержимого. Дайджест MD5 является 128-разряд-

иой контрольной суммой и представляется в HTTP в виде 32-х отображаемых сим-

волов ASCII. Биты преобразуются от старших к младшим, группами по четыре

бита в шестнадцатеричные цифры от

до f (например, битовая строка 1010 пред-

ставляется шестнадцатеричной цифрой а, а 0100

—

шестпадцатеричной цифрой 4).

Дайджест позволяет получателю убедиться, что полученное содержание яъляелся

точно тем же, которое было отправлено. Заголовок Content-MD5 могут использо-

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

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

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

Распространенной в Internet угрозой является атака отказа от обслуживания

(DoS — Denial of Service). В Web DoS-атака может принимать множество форм,

включая передачу Web-серверу сообщений большого объема. Сообщения большого

объема могут переполнить буферы и также привести к нарушению безонас1юсти.

DoS -атака

—

это классическая проблема, с которой сталкиваются серверы; если бы

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

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

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

тела содержимого сообщения до обработки запроса. Это стандартный способ гаран-

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

большого объема. Однако если сообщение разбито на фрагменты (см. раздел 7.6),

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

щий НТТР/1.1, обязан анализировать сообщения разбитые на фрагменты. Однако

сервер в любой момент может принять решение, что сообщение слишком велико и

отправить код ответа 411 Length Required и затем закрыть соедините.

Новый код ответа 414 Request-URI Too Long может быть возвращен, если сер-

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

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

венными ограничениями, чтобы установить соответствующее значение. Хороший

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

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

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

ва1Н1ые строковые буферы и не отслеживают переполнение, могут допустить пере-

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

пасности.

Обеспечению безопасности в НТТР/1.1 уделено серьезное внимание: предот-

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

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

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

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

7.11.

Роль прокси-серверов в НТТР/1.1

Одним из решающих улучшений в НТТР/1.1 было осознание той важной роли,

которую играют промежуточные компоненты между отправителем и получателем.

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

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

вера стала центральной в архитектуре Web. Структура и детали организации про-

кси-серверов были изложены в главе 3. В частности, вопросы, относящиеся к про-

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

смотрены в главе 3 (раздел 3.4.2). Чтобы сосредоточить внимание на той роли,

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

на четыре части, следующим образом.

• Типы прокси-серверов.

• Синтаксические требования, предъявляемые к прокси-серверам в НТТР/1.1.

• Семантические требования, предъявляемые к прокси-серверам в НТТР/1.1.

• Влияние других компонентов Web на прокси-серверы в НТТР/1.1.

7.11.1.

Типы прокси-серверов

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

ходным сервером, также существуют более сложные решения в виде иерархиче-

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

В том, что касается протокола НТТР/1.1, существует три разных схемы функцио-

нирования прокси-серверов.

• Прокси-сервер действует в качестве посредника с другими системами, поддер-

живая ряд протоколов, таких как WAIS, FTP или Gopher.

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

понентом между отправителем и получателем HTTP-сообщений.

• Прокси-сервер играет роль прокси-сервера HTTP, клиента или туннеля в раз-

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

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

ЛН1,

в НТТР/1.1 не было введено никаких новых требований. Они продолжают

функцио1Н1ровать так же, как они это делали в соответствии с НТТР/1.0.

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

лать это удовлетворительпо, то есть его ответ гарантированно актуален. Гарантия

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

кси-сервер может передать запрос дальше по цепочке. Когда спустя какое-то время

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

Глава 7. HTTP/1.1 283

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

изменить запрос или ответ.

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

гда используется метод CONNECT. Хотя в спецификации НТТР/1.1 этот метод

просто зарезервирован, он использовался при инициировании Transport Layer

Security (TLS) [KLOOJ поверх существующего TCP-соединения посредством меха-

низма Upgrade.

7,И,2. Синтаксические требования к прокси-серверу,

поддерживающему НТТР/1.1

в НТТР/1.1 к прокси-серверу предъявляются следующие два класса основных

синтаксических требований:

• Требование, связанные с передачей сообщений.

• Требования, связанные с изменением существующих заголовков или добавле-

нием новых.

Далее мы рассмотрим оба эти требования.

ПЕРЕДАЧА СООБЩЕНИЙ

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

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

это сообщение. Предположим, что прокси-сервер, поддерживающий НТТР/1.1, пере-

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

НТТР/1.0. Даже если этот прокси-сервер получил ответ НТТР/1.1 от ближайшего

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

тель,

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

рые из возможных аспектов этого сообщения НТТР/1.1. Однако если исходный от-

правитель правилыю воспринимает НТТР/1.1, прокси-сервер, поддерживающий

НТТР/1.1,

может возвратить ответ НТТР/1.1 нетронутым. На самом деле в специ-

фикации предполагается, что прокси-сервер сохраняет в кэше гюмер версии своего

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

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

пример, прокси-сервер не может передать ответ 100 Continue, если прокси-серве-

ром добавлен заголовок Expect (т.е. заголовок Expect отсутствовал в исходном со-

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

рый не соответствует его возможностям, он должен вернуть ответ 417 Expectation

Failed вне зависимости от того, обладает ли следующий за ним сервер требуемыми

возможностями. Связано это с тем, что механизм Expect является механизмом

промежуточных передач.

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

заголовка Max-Forwards (см. раздел 7.7.1) и то, что его значение не равно нулю.

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

дать сообщение дальше. Аналогично, запрос без заголовка Host от клиента, поддер-

живающего НТТР/1.1, не должен передаваться прокси-сервером дальше; вместо

этого прокси-сервер должен вернуть 400 Bad Request.

Заголовки, не воспринимаемые прокси-сервером, должны по-прежнему пересы-

латься дальше, если только они не перечислены в заголовке Connection (описан-

ном в разделе 7.5). Прокси-серверы должны осторожно обрабатывать заголовки

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

284

Часть

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

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

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

Connection, прежде чем пересылать сообщение дальше.

ДОБАВЛЕНИЕ ЗАГОЛОВКОВ ИЛИ ИЗМЕНЕНИЕ СУЩЕСТВУЮЩИХ ЗАГОЛОВКОВ

Прокси-серверы, поддерживающие НТТР/1.1, обязаны добавлять информацию

о себе в заголовке Via, как это обсуждалось в разделе 7.7. Прокси-серверы должны

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

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

шлюзом сети (например, функционирующий как сетевой экран), должен скрывать

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

формацию о них в заголовки Via.

Прокси-серверы, поддерживающие НТТР/1.1, не могут изменять порядок зна-

чений полей в заголовках сообщений, так как при этом может измениться их се-

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

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

мер,

ETag, Content-MD5) и поля в заголовках Expires не должны изменяться

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

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

Content-Encoding, Content-Type). Прокси-сервер не должен изменять заголовок

запроса From (указывающий адрес электронной почты пользователя, пославшего

этот запрос) и заголовок ответа Server (идентифицирующий программное обеспе-

чение и номер версии Web-сервера).

Прокси-серверам не разрешается изменять полностью определенное имя доме-

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

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

разрешается добавить имя домена к имени хоста. Прокси-серверам не разрешается

генерировать некоторые заголовки (например, сквозной заголовок проверки цело-

стности Content-MD5; см. раздел 7.2.2). Прокси-сервер может, тем не менее, ис-

пользовать значение, представленное в заголовке Content-MD5, чтобы проверить

корректность тела полученного им сообщения.

7.11.3.

Семантические требования к прокси-серверу,

поддерживающему НТТР/1.1

Семантические изменения в НТТР/1.1, касающиеся прокси-серверов, являются

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

менные соединения и обеспечение безопасности.

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ С КЭШИРОВАНИЕМ

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

кси-серверы играют главную роль в кэшировании, то изменения в этой области

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

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

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

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

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

тов.

При наличии директивы управления кэшем Cache-Control: s-maxage=0 кэш

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

Глава 7. HTTP/1.1 285

Если прокси-сервер действует в качестве кэша и возвращает кэшированные отве-

ты,

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

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

Заголовок Age включает оценку времени, прошедшего с момента нервонача;шной ге-

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

точником. Получатель может использовать значение Age для оценки возраста ответа.

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ С УПРАВЛЕНИЕМ СОЕДИНЕНИЕМ

Прокси-серверы, поддерживающие НТТР/1.1 и реализующие долговременные

соединения, должны обеспечивать долговременность и восходящего (но направле-

нию к исходному серверу), и нисходящего (по направлению к клиенту) соедине-

ний. В НТТР/1.0 существовала реализация долговременного соединения (заголо-

вок Keep-Alive), которая требовала явного согласования. Однако взаимодействие

заголовков Connection и Keep-Alive может привести к «зависанию» соединения.

Это происходит из-за того, что клиент НТТР/1.0 может послать заголовок Keep-

Alive прокси-серверу, который не воспринимает Connection, но может ошибочно

передать его дальше. Если нисходящее соединение также поддерживает соединение

Keep-Alive, находящийся в середине прокси-сервер никогда не получил бы завер-

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

держивающим НТТР/1.1, не разрешено устанавливать долговременное соединение

с клиентами, поддерживающими НТТР/1.0.

Прокси-серверы могут использовать различные наборы правил (но сравнению

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

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

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

клиентов. У прокси-сервера обычно меньше клиентов, чем у популярного Web-cep-

вера. И поэтому прокси-серверу «виднее», какие соединения поддерживать откры-

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

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

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

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

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

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

временных соединений с любым сервером или прокси-сервером. Прокси-сервер

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

ми,

где п

—

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

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ С УПРАВЛЕНИЕМ

ПОЛОСОЙ ПРОПУСКАНИЯ

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

на прокси-сервер специфические ограничения. Если прокси-сервер пересылает за-

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

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

кси-сервер должен весь ответ. Однако если кэш прокси-сервера не поддерживает

запросы на диапазоны, то он не должен кэшировать частичные ответы.

Для прокси-серверов, поддерживающих НТТР/1.1, существуют дополнитель-

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

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

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

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

286

Часть

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

кси-серверы, поддерживающие НТТР/1.1, обязаны пересылать заголовок Expect

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

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

ответ 417 Expectation Failed, а не пересылать запрос дальше. Аналогично, если

прокси-сервер получил от сервера ответ 100 Continue, он не должен пересылать

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

заголовок Expect.

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ С ОБЕСПЕЧЕНИЕМ

БЕЗОПАСНОСТИ

Некоторые заголовки и коды ответов были введены для удовлетворения требо-

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

заголовки запросов, такие как Proxy-Authenticate, и коды ответов, такие как 407

Proxy Authorization Required.

Заголовок запроса Proxy-Authenticate требуется тогда, когда ресурс доступен

только для клиегггов, прошедших аутентификацию. Клиент должен предоставить

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

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

кационные данные.

Код ответа 407 Proxy Authorization Required похож па код ответа НТТР/1.0

401 Unauthorized. Однако 407 Proxy Authorization Required служит для аутенти-

фикации ближайшего участника соединения в отличие от сквозного заголовка 401

Unauthorized. Код ответа 407 Proxy Authorization Required используется про-

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

на доступ к прокси-серверу, тогда как ответ 401 Unauthorized используется исход-

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

лает заголовок аутентификации Proxy-Authenticate клиенту с вызовом, указав

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

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

1ЮВ0Г0 заголовка запроса Proxy-Authorization.

7.12. Различные изменения

в НТТР/1.1 по сравнению с НТТР/1.0 есть и другие незначительные измене-

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

категорий, разделив эти изменения на три части: относяидиеся к методам, к заго-

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

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

7.12.1.

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

Семантика отдельных методов НТТР/1.0 была изменена незначительно. В не-

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

лись методов HEAD, PUT, DELETE и CONNECT.

НЕЗНАЧИТЕЛЬНОЕ ИЗМЕНЕНИЯ МЕТОДА HEAD

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

(такими как If-Modified-Since), в НТТР/1.1 нет таких офаничений. Условные заго-

ловки в НТТР/1.1 можно использовать с любым методом. Спецификация НТГР/1.1

Глава

HTTP/1.1

287

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

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

УТОЧНЕНИЯ МЕТОДА PUT

Метод PUT был частично описан в RFC 1945, как часть НТТР/1.0. Последую-

щие дискуссии в HTTP Working Group привели к общему решению о его формаль-

1ЮМ

определении в качестве метода НТТР/1.1. Web-сервер, обрабатывающий запрос

PUT,

проверяет URI запроса, чтобы определить будет ли запрос модифицировать

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

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

ном определении метода были добавлены отдельные требования к Web-серверам и

кэширующим прокси-серверам. Например, Web-сервер должен отвечать 201 Cre-

ated, если ресурс был создан в результате запроса с методом PUT. Если ресурс, ука-

занный в методе PUT (также как POST и DELETE) был помещен в кэш, кэширо-

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

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

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

с этим ресурсом.

В следующем примере запрос с методом PUT используется для создания или

модификации ресурса /foobar/foo.html:

PUT /foobar/foo.html HTTP/1.1

User-Agent: Mozilla/2.0

Authorization: Basic ZHeadFuaYow29PinWU=

Content-Type: text/html

Content-Length: 433

Host: bar.com

<433 байта возможно нового foo.html>

Этот запрос включает информацию о типе содержания и его длине, также как

идентификационные данные в заголовке Authorization. Идентификационные дан-

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

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

достаточны, сервер создает или модифицирует /foobar/foo.html, а также возвраща-

ет ответ 200 ОК.

Сравнение методов PUT и POST. Различия. В процессе формализации опреде-

ления метода PUT возникали вопросы о различии методов PUT и POST. Чтобы

понять разницу между методами PUT и POST, нужно рассмотреть, как осуществ-

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

только

к дангюму URI и, если он не может этого сделать, вернуть ответ, относя-

щийся к классу нереадресации. Ресурс может быть создан или изменен. Ресурс

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

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

заполняет форму как составную часть запроса.

МЕТОД DELETE. ФОРМАЛИЗАЦИЯ

Как и PUT, метод DELETE рассматривался в приложении к RFC 1945, но не

был формально определен. Метод DELETE приводит к удалению ресурса, ассоции-

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

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

причинам на Web-сервере. Web-сервер, например, может проверить права доступа

инициатора запроса и принять решение не удалять ресурс. В этом случае, сервер

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

тив ответ 401 Unauthorized или 403 Forbidden.

В НТТР/1.1 требования к компонентам, связанные с реакцией на метод

DELETE, определены ясно. Например, в протоколе определены коды ответов, ко-

торые должен послать Web-сервер, если удаление выполнено успешно. Про-

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

копию как устаревшую.

МЕТОД CONNECT

Метод CONNECT используется для создания «туннеля» между двумя про-

кси-серверами и был предложен Ари Луотопеном [Luo97J в 1998 г. в рабочем проек-

те стандарта (теперь уже устаревшем). Он не был формально стандартизован. Но-

вый метод

—

CONNECT

—

был зарезервирован в НТТР/1.1 в роли «заполнителя»

(то есть для гарантии, что этот метод не будет зарезервирован в будущем для како-

го-то другого применения). Хотя имя этого метода зарезервировано для будущего

применения, одно специфическое применение в RFC упомянуто — прокси-сервер,

в целях обеспечения безопасности, способен превратиться в «туннель». Иначе гово-

ря,

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

лучает. Метод CONNECT в НТТР/1.1 [KLOOJ используется для инициирования

Transport Layer Security (TLS) поверх существующего ТСР-соедипепия, для про-

кладки «туннелей» через прокси-серверы.

7.12.2. Различные изменения, относящиеся к заголовкам

Некоторые заголовки НТТР/1.0 были немного изменены, некоторые новые за-

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

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

жимого.

ОБЩИЕ ЗАГОЛОВКИ

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

в заголовке Transfer-Encoding, чтобы получатель знал, как анализировать тело сооб-

щения. В НТТР/1.0 не было гарантии (при отсутствии заголовка Content-Length),

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

рование при передаче позволило гарантировать, что получатель получил все, что

было отправлено. Заголовок Transfer-Encoding

—

заголовок промежуточных передач

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

В результате введения заголовка Transfer-Encoding в НТТР/1.1, по сравнению

с НТТР/1.0, изменилось определение НТТР-сообщепия (и запроса, и ответа).

В НТТР/1.0, чтобы получить тело содержимого, достаточно было удалить только

заголовки сообщения, а в НТТР/1.1 исходное сообщение нужно еще и восстано-

вить,

применив к нему преобразование, обратное кодированию при передаче.

ЗАГОЛОВКИ ОТВЕТОВ

Один заголовок НТТР/1.0 (Retry-After) был изменен в НТТР/1.1 и был добав-

лен новый заголовок Warning.

Заголовок Retry-After рассматривался в приложении к спецификации НТТР/1.0

в контексте несовместимых реализаций протокола. Тем пе менее, этот заголовок не

Глава 7. HTTP/1.1

289

стал частью спецификации НТТР/1.0. Он был введен в НТТР/1.1 для уточнения се-

мантики кода ответа 503 Service Unavailable. Существуют две причины обусловли-

вающие этот код ответа: сервер в течение неопределенного времени работает в авто-

номном режиме,

—

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

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

может повторить запрос после указанного интервала времени. Значение времени

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

в будущем. В НТТР/1.1 заголовок Retry-After используется с несколькими ответа-

ми,

включая 413 Request Entity Too Large (раздел 7.2.3) и ответами переадресации

класса (Зхх).

Первые сообщения об ошибках в НТТР/1.0 не были предназначены для чтения

их человеком. Классы ошибок 4хх и 5хх включают короткие и простые фразы на

естественном языке, но из этих фраз нельзя извлечь информацию о возможных

корректных действиях. К сожалению, код состояния и строка сообщения появля-

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

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

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

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

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

цию,

поясняющую предупреждающее сообщение. Обратите внимание, что эти коды

предупреждений не относятся к общим кодам ответов HTTP. Как показано в таб-

лице 7.15, в НТТР/1.1 определено семь кодов предупре}1^дений.

Таблица 7.15. Коды предупреждений НТТР/1.1

Г—^—^ —^ ^—

Код предупреждения (warning)

110 Response is stale

111 Revalidation failed

112 Disconnected operation

113 Heuristic expiration

199 Miscellaneous warning

214 Transformation applied

299 Miscellaneous persistent

1 warning

Краткое описание |

Кэш предупреждает, что возвращенный ответ устарел

Неудачная попытка проверить актуальность ответа

Кэш отключен от сети

Срок годности определен на основе эвристики

Предупреждение для вывода пользователю

Кодирование или тип содержания изменены

Предупреждение класса 2хх для вывода пользователю

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

появление дополнительных кодов.

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

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

разовал ответ в другой формат. Было бы полезно указать на этот факт в предупреж-

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

виде. Прокси-сервер может включить заголовок Warning следующим образом:

Warning: 214 Transformation applied

Аналогично, если прокси-сервер собирается вернуть ответ из кэша из-за невоз-

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

то,

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

Warning:

111

Revalidation failed