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

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

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

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

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

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

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

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

находящегося на пути к Web-серверу.

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

выше в цепочке к исходному серверу и претендующий на соответствие

с НТТР/1.1, чтобы узнать, может ли он работать с конкретной возможностью

HTTP/1.1,

например. Expect.

По всем перечисленным причинам в НТТР/1.1 был введен новый метод

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

но и любому серверу на пути от отправителя к получателю. Метод OPTIONS, по-

добно методам GET и HEAD, является безопасным методом.

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

может отправить следующий запрос OPTIONS:

OPTIONS * НТТР/1.1

Host: foo.com

Сервер может ответить так

НИР/1.1 200 ОК

Allow: HEAD. GET. POST. TRACE. OPTIONS

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

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

бой "*". Это означает, что клиента интересуют возможности сервера, а не какого-то

конкретного URI. Для конкретного URI заголовок ответа Allow вернет набор мето-

дов,

применимых к данному ресурсу.

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

вере,

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

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

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

серверу. Для того чтобы клиенты могли получить ответ от конкретного прокси-сер-

вера, в НТТР/1.1 был введен новый заголовок запроса. Клиент задает значение для

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

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

щий прокси-сервер должен ответить на запрос OPTIONS. Заголовок Max-Forwards

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

жения циклов в цепочке прокси-серверов. Это поле похоже на ноле времени жизни

(TTL) в IP-пакетах (об этом говорилось в главе 5, раздел 5.1.4).

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

чи данных:

OPTIONS /bar НТТР/1.1

Host: foo.com

User-Agent: Mozilla/2.0

Max-Forwards:

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

ловка Мах-Forwards и передаст запрос следующему получателю. Второй получа-

Глава

HTTP/1.1

271

гель в цепочке должен ответить на запрос, так как значение Max-Forwards теперь

равно нулю.

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

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

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

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

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

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

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

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

шить в ответах на запросы с заголовком OPTIONS возвращать информацию о со-

вместимости, например, о совместимости с конкретной версией стандарта или несо-

вместимости но отношению к одной из его возможностей. Однако из-за неопреде-

ленности связанной с термином

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

и из-за увеличения сложности, эта

возможность не была введена в HTTP. Было добавлено расширение в виде DAV, за-

головка для расширения HTTP, называемое WebDAV [GWF^99J, которое обеспечи-

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

дается в главе 15 (раздел 15.5.2). WebDAV позволяет осуществлять удаленную раз-

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

форматов тела содержимого. Сервер WebDAV при гюлучении запроса с заголовком

OPTIONS может перечислить свои возможности с помощью заголовка DAV. На-

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

(уровень требований MUST), но не поддерживает блокировку. Заголовок DAV:1, 2

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

МЕТОД TRACE

Метод TRACE, введенный в НТТР/1.1, позволяет клиенту узнать содержание

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

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

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

В методе TRACE все содержимое сообщения-запроса сервер возвращает отпра-

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

дующий запрос:

TRACE /bar HTTP/1.1

Host: foo.com

User-Agent: Mozilla/2.0

результатом должен быть следующий ответ:

НТТР/1.1 200

ОК

Content-type: message/http

TRACE /bar НТТР/1.1

Host: foo.com

User-Agent: Mozilla/2.0

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

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

мого.

Заголовок Content-type используется, чтобы указать, что ответ на запрос

с методом TRACE имеет тин message/http. Тин message/http указывает, что тело

ответа является HTTP-запросом или ответом и что он подчиняется соответствую-

272

Часть

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

щим соглашениям MIME для данного типа (например, предельному значению дли-

ны строки и допустимым схемам кодирования).

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

ние его обратно) не является чем-то новым, имеющимся только в HTTP. В других

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

[Jacj (см. главу 5, раздел 5.1.4). Команда traceroute отслеживает маршрут, который

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

с различными значениями TTL и затем осуществляя прием по протоколу Internet

Control Message Protocol (ICMP) ответов TIME_EXCEEDED, приходящих от мар-

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

7.7.2. Получение информации о промежуточных серверах

HTTP/1.1 уделяет больше внимания промежуточным средствам в цепи транзак-

ций запрос-ответ. Промежуточное средство в НТТР/1.1 (прокси-сервер или шлюз)

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

получил сообщение, в новом заголовке Via.

Заголовок Via является средством расширения и обеспечения взаимодействия

для клиентов и серверов, использующих НТТР/1.1. Когда пользователь создает

Web-3aiipoc, то этот запрос может пройти через несколько промежуточных серве-

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

верами, шлюзами или внешними интерфейсами серверов. Аналогично, Web-сервер

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

через которые проходит запрос. Фактически, любые из серверов, входящих в це-

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

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

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

хосты но пути следования 1Р-накета была реализована в утилите traceroute [Jас]

почти за десятилетие до появления Web. Заголовок Via является частичным вос-

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

Сам заголовок Via был создан после определения поля Received в RFC 822 (стан-

дарт формата текстовых сообщений Internet [Cro82j). Он также похож на меха-

низм в протоколе Border Gateway Protocol (ВОР) [RL95, Ste99], где каждая авто-

номная система добавляет свой помер (ASN) к атрибуту AS-PATH.

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

му заголовку с названием Forwarded [FFBL95]. Этот заголовок предназначался

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

сюда включались только имена серверов между клиентом и Web-сервером. После

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

ловок Forwarded был переименован в заголовок Via.

Все НТТР/1.1 прокси-серверы и шлюзы обязаны участвовать (это требование

уровня MUST) в механизме Via. Промежуточные средства обязаны идентифици-

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

прос или ответ. Из соображений конфиденциальности промежуточное средство

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

или шлюзы, использующие НТТР/1.1 (хотя на практике прокси-серверы, исполь-

зующие НТТР/1.0, также могут принимать в этом участие) добавляют идентифи-

кационную информацию к новому общему заголовку Via последовательно по мере

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

имеет информацию о серверах но пути следования. Хотя это не так уж необычно

Глава 7. HTTP/1.1 273

встретить прокси-серверы, использующие HTTP/1.0, которые были избирательно

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

HTTP/1.0 прокси-серверов о механизме Via ничего неизвестно.

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

Via:

1.0

M-PR0XY3:8080 (Squid/2.1.РАТСН2),

1.0 tl.us.irc.net:3128 (Squid/2.3.DEVEL1),

1.1 qd.us.ircache.net:3128 (Squid/2.3.DEVEL1)

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

ханизме Via. Первый элемент в заголовке Via

1.0 M-PR0XY3:8080 (Squid/2.1.РАТСН2)

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

компьютеру M-PROXY3, и на нем функционировал прокси-сервер Squid 2.1 на пор-

ту 8080. Последним из промежуточных средств, участвовавших в механизме Via, яв-

ляется qd.us.ircache.net, на котором па порту 3128 функционировал прокси-сервер

Squid 2.3, а его предшественником был сервер, поддерживающий НТТР/1.1.

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

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

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

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

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

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

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

па пути сообщения. Заголовок Via является сквозным заголовком, и поэтому все

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

Заголовок Via используется в сочетании с методом TRACE (обсуждался в раз-

деле 7.7.1) для получения информации о пути, пройденном НТТР-сообщеиием. За-

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

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

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

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

из прокси-серверов, находящихся на пути сообщения. Возможно, это не одноразо-

вое действие; клиенту может быть придется повторить эту операцию несколько

раз,

пока он сможет локализовать конкретный прокси-сервер. Несколько про-

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

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

соображениям обеспечения безопасности и конфиденциальности. Также как и

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

чить число переходов, которые пройдет запрос с методом TRACE.

Механизм Via также можно использовать, чтобы избежать циклов на пути за-

проса. При обнаружении своего имени в заголовке Via прокси-сервер может при-

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

7.7.3.

Переход к другим протоколам

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

лов.

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

в НТТР/1.1 был введен новый заголовок промежуточных передач Upgrade. Когда

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

274

Часть

III.

Web-протоколы

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

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

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

переключился с помощью заголовка ответа 101 Switching Protocols.

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

НТТР/1.1,

выражают желание перевести существующее между ними соединение

на другой протокол.

GET http://security.are.us/private-data НТГР/1.1

Host: chase.bronx.com

Upgrade: SafeBank/1.0

Connection: Upgrade

Клиент запрашивает ресурс security.are.us/private-data и извещает, что он мо-

жет работать по протоколу SafeBank/1.0. Сервер chase.bronx.com может ответить

по протоколу НТТР/1.1 или в качестве альтернативы переключиться на протокол

SafeBank/1.0 и сообщить об этом с помощью кода ответа 101 Switching Protocols:

НТТР/1.1 101 Switching Protocols

Upgrade: SafeBank/1.0

Connection: Upgrade

<Ответ на запрос клиента>

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

уровня может теперь выполняться по протоколу SafeBank/1.0. Чтобы использо-

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

жен использовать соответствующие ответы переадресации класса (Зхх).

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

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

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

нимает этот заголовок, или не намерен переходить на другой протокол. Обратите

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

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

7.8.

Сбережение Internet-адресов

в Internet используется четвертая версия протокола IP, который предоставляет

максимум 2^^ адресов хостов. В течение нескольких лет количество адресов, пре-

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

ность Web и быстрое осознание частью бизнесменов, что короткие имена Web-сай-

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

Web-сайтов типа www.foo.com. Эти «чистые» URL хостов состоят только из име-

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

дельного IP-адреса в реализациях НТТР/1.0.

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

www.foo.com для того, чтобы получить ресурс http://www.foo.com/bar.html,

в первой строке запроса содержится только

GET /bar.hml НИР/1.0

Агент пользователя удаляет имя сервера из URL в HTTP-запросе. Имя сервера

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

Глава 7. HTTP/1.1 275

времени, когда HTTP-сервер получил сообщение, в нем больше не было надоб-

ности.

Популярность Web привела к появлению компаний, занимающихся Web-хос-

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

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

Web-хостингом, управляют Web-сайтами большого числа компаний. Тем не менее,

каждая компания изъявляла желание иметь для сайта собственное доменное имя

(например, http://www.foo.cojn), а не доменное имя какой-то другой компании,

занимающейся Web-хостингом (например, www.hostmany.com/foo). Неспособ-

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

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

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

вающего ресурс http://www.serverA.com/bar.html. Web-сервер с доменным име-

нем www.serverA.com получит следующий запрос:

GET /bar.html НТТР/1.0

В этой ситуации другой Web-сервер не может работать на том же хосте под другим

доменным именем www.serverB.com, поскольку при этом появляется неоднознач-

ность в интерпретации запроса для /bar.html. Оба сервера в равной степени могут

иметь право ответить на этот запрос, и не существует способа разрешить эту неод-

гюзначность.

Желание иметь «престижные» URL привела к назначению отдельных IP-адре-

сов для каждого доменного имени. Быстрое увеличение числа Web-сайтов и рост

популярности Internet привели к быстрому уменьшению числа свободных IP-адре-

сов.

Новая версия IPv6 [DH98J может помочь избежать недостатка IP-адресов.

В IPv6 адреса являются 128-разрядными, что разительно увеличивает число дос-

тупных адресов по сравнению с 32-разрядным адресным пространством IPv4. На

момент публикации данной книги большей части Internet еще только предстоит

перейти на IPv6.

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

венный за координацию процесса стандартизации, уполномочил HTTP Working

Group принять меры по сбережению IP-адресов в процессе перехода на НТТР/1.1.

У HTTP Working Group был вариант изменить строку запроса, чтобы включить

имя хоста следующим образом:

GET www.foo.com/bar.hml НТТР/1.0

Однако существующие НТТР/1.0 сервера не смогут правильно обрабатывать такую

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

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

ложено ввести заголовок Original-URI, который содержал бы нолньпЧ URI (включая

имя сервера). В процессе дискуссий по развитию протокола, было решено, что такой

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

строка заголовка Host. Приведенный выше запрос в НТТР/1.1 выглядит так

GET /bar.hml НТТР/1.1

Host: www.foo.com

Все запросы в НТТР/1.1 должны иметь ноле заголовка Host. Можно также

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

с номером 80. Серверы, поддерживающие НТТР/1.1, которые получают запрос от

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

кой запрос. Надежда здесь на то, что такое строгое требование поможет сберечь

276

Часть

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

IP-адреса. Поскольку клиентам, поддерживающим НТТР/1.0, ничего неизвестно о

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

у которых нет данного заголовка.

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

ное имя, например, www.foo.com. Множество доменных имен может отображаться

на IP-адрес с помощью DNS. Такой метод виртуалыюго хостинга позволяет Web-

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

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

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

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

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

ют использовать НТТР/1.0, вюиочают в сообщение заголовок Host.

7.9. Согласование содержания

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

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

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

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

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

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

ния представлена па английском языке [LG99J. Содержимое, представленное на

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

русском, датском). С ростом Web и по мере того, как одно и то же содержание ста-

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

ности выбора различных вариантов одного и того же ресурса. Ресурсы отличались

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

ных наборов символов, например, ASCII, ISO (включая кодировки латиницы или

кириллицы), сжатия (gzip и т.д.), зарегистрированы в Internet Assigning Numbers

Authority (IANA). Согласование содержания в HTTP было разработано, чтобы по-

мочь клиентам и серверам договариваться о форматах ресурса.

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

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

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

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

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

В 1993 г. в одном из первых проектов HTTP [BL93a] довольно детально обсуж-

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

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

как Accept и Accept-Charset. Браузер Mosaic включал заголовки Accept в свои за-

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

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

ставляющей интерес для HTTP Working Group [Sec95J. Поскольку к моменту за-

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

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

Charset, Accept-Encoding, Accept-Language и Content-Language) была вынесена

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

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

Глава 7. HTTP/I Л 277

• Управляемое агентом. При управляемом агентом согласовании содержания

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

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

• Управляемое сервером. При управляемом сервером согласовании содержа-

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

вер,

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

мер,

па его IP-адресе.

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

гласования привела к отделению этих усилий от работы над спецификацией HTTP.

В НТТР/1.0 из-за отсутствия согласования, управляемого агентом, у пользовате-

ля было меньше возможностей выбора конкретного варианта ресурса. В НТТР/1.1

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

он готов принять (например, текст или аудио). Рассмотрим следующий пример:

GET /asterix.html НТГР/1.1

Host: www.getobelix.com

Accept-Language: en-us, fr-BE

Агент пользователя запрашивает ресурс asterix.html и готов принять или вари-

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

может выбрать между этими вариантами и вернуть ответ в следующем виде:

НТТР/1.1 200 ОК

Content-Length: 23819

Content-Language: fr-BE

<вариант ответа на бельгийском французском языке>

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

языке, как это указано в заголовке Content-Language. Заголовок содержимого

Content-Language указывает па естественный язык тела содержания и, следователь-

но,

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

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

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

если содержимое может восприниматься более широкой аудиторией. Вот пример ис-

пользования заголовка Content-Language с несколькими языками

Content-Language: en-cockney, x-pig-latin

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

(диалекте английского языка), или для тех, кто говорит на Pig Latin (одном из ва-

риантов латинского языка).

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

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

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

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

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

^^ля^тся Web-сервер.

НТТР/1.1 разрешает серверу иметь свой собственный алгоритм генерации спи-

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

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

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

278 Часть IIL Web-протоколы

ca на другой вариант содержания. Если запрашиваемый формат отсутствует,

сервер может вернуть ответ 406 Not Acceptable. Код 406 Not Acceptable был вве-

ден для реализации управляемого агентом согласования. Сервер также включает

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

выбрать из числа доступных вариантов. Оборотной стороной ответа 406 Not

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

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

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

Accept. Спецификация считает, что предпочтительнее вернуть вариант, отличный

от тех, которые перечислены как приемлемые, чем ответ 406 Not Acceptable.

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

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

фигурационный файл сервера является подходящим местом для определения алго-

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

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

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

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

полнить эту задачу автоматически.

Код ответа 300 Multiple Choices в НТТР/1.1 был расширен в основном в ре-

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

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

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

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

ля сделать правильный выбор.

Одним из способов для агентов пользователя и исходных серверов определить

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

вестные в HTTP как qvalue. Как отмечалось в разделе 7.4.3, qvalue — это число

в диапазоне от 0.0 до 1.0, где меньшее значение оценки качества указывает на мень-

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

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

описывающего согласование содержания [BL93a], но формализованы были только

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

вания. Вес конкретного параметра может теперь задаваться и в запросе, и в ответе.

Смысл нулевой оценки качества заключается в том, что содержание с этим конкрет-

ным значением параметра неприемлемо для клиента. К сожалению, термин оценка

качества был выбран до полного определения области его применения; на самом

деле оценки качества задают снижение качества относительно идеального уровня.

Оценка качества 1.0 является идеальной, а 0.9 на 10% хуже, чем искомый идеал.

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

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

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

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

Accept-Encoding: vdelta;q=1.0, gzip;q=0.5, compress;q=0.1

Этот пример показывает, что клиент отдает наибольшее предгючтение кодировке от-

вета vdelta. Если сервер не может предложить клиенту этот формат, тогда следует по-

пробовать предложить ресурс в формате gzip, а если и это не получается, то в формате

compress. В этом примере сервер может посылать ответ в одном из указагп1ых форма-

тов или в своем собственном формате. Если клиент вместо этого задал бы

Accept-Encoding: vdelta;q=l.О, gzip;q=0.5, compress;q=0.1, identity;q=0

Глава 7. HTTP/1.1 279

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

(vdelta, gzip, compress), или послать код ответа 406 Not Acceptable. Если опусти гь

строку identity;q=0, то сервер мог бы послать ответ в кодировке по своему выбору.

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

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

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

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

ны.

Существует значительное расхождение между объемом передаваемой и реально

используемой обеими сторонами информации. Сервер может быть гибким в выборе

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

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

держания

—

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

Согласованные ответы, хранящиеся в кэше, требуют более аккуратного отноше-

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

ложением. В НТТР/1.1 это осуществляется с помощью нового заголовка ответа

Vary и с помощью заголовков содержимого Content-Location. Нагюминаем о том,

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

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

жение содержания в запросе; оно отличается от URI ресурса в запросе.

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

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

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

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

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

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

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

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

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

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

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

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

как кэш мог бы отслеживать изменения на сервере. HTTP Working Group решила

убрать прозрачное согласование содержания из спецификации НТТР/1.1, работа над

этим продолжается независимо [НМ98]. Прозрачное согласование содержания обсу-

ждается более подробно в главе 15 (раздел 15.5.1).

7.10. Безопасность, аутентификация

и целостность

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

прошедшие аутентификацию, получат доступ к ресурсам. Сообщения, которыми

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

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

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

назначено. Рассмотрим письмо, посылаемое по почте от А к В:

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

• В нужен способ убедиться, что данное письмо действительно пришло от А.