Transparent Content Negotiation

Идея (TCN) [HM98] возникла в ходе обсуждения рабочей грунной HTTP Working Group проблемы выбора варианта содержания в зависимости от требований клиента. Вопросы выбора варианта содержания подробно обсуждались в главе 7 (раздел 7.9). Клиенту предоставляется возможность выразить свои предпочтения при выборе варианта ресурса из числа доступных на исходном сервере. В качестве примера таких предпочтений можно привести выбор языка или набора символов.

В целом процесс выбора варианта содержания достаточно очевиден: клиент выра- жает предпочтение и, если предпочтение приемлемо для исходного сервера, ресурс возвращается в соответствующем формате. В процессе обсуждения перехода от НТТР/1.0 в НТТР/1.1 возможности выбора варианта содержания НТТР/1.0 были значительно расширены. Поддержка протоколом НТТР/1.0 выбора варианта содержания требовала от клиентов указания приемлемых языков, наборов символов и т.д., чтобы сервер мог выбрать наилучший возможный вариант ресурса. Предоставляя клиенту возможные значения (или диапазон значений), такой механизм не допускает расширения. Как говорилось ранее в главе 7, в НТТР/1.1 были введены две формы выбора варианта содержания: с управлением на стороне агента пользователя и с управлением на стороне сервера. TCN представляет собой комбинацию этих двух способов с целью использования кэшей, расположенных на пути между клиентом и исходным сервером. Дружественность по отношению к кэшам является важным добавлением в НТТР/1.1, реализованным через заголовки Vary и If-None-Match. TCN использует дополнительную поддержку кэширования в НТТР/1.1 для выбора варианта содержания с помощью агента пользователя. Такое решение дает пользователю возможность явного выбора из множества вариантов.

Основным заголовком, используемым в TCN, является заголовок ответа Alternates, который передает список вариантов, ассоциированных с ресурсом. Например, копия этой книги может быть доступна в различных форматах при обращении к URI http://www.research.att.com/"bala/books/kandr. Одна версия книги может быть представлена в формате PostScript, другая — в виде большого контейнерного HTML-документа, а еще одна, переведенная на санскрит, доступна на Devanagari Script в виде документа в формате Portable Document Format (PDF). Поскольку ответ доступен в различных форматах, используется код ответа 300 Multiple Choices. Если сделан запрос на книгу, исходный сервер может включить заголовок ответа Alternates в свой ответ, например, следующим образом:

НТТР/1.1 300 Multiple Choices Date: Sun, 2 Jul 2000 17:45:43 GMT

Alternates: {"book.html" 1.0 {type text/html} {language en}}, {"book_ss.pdf" 1.0 {type application/pdf} {language ss}}, {"book.ps" 0.9 {type application/postscript} {language en}}, {"book.doc" 0.5 {type application/word} {language en}} Vary: negotiate, accept-language ETag: "krbk2921103-2311-dtee" Content-Type: text/html Content-Length: 212

<h2>Multiple Choices:</h2> <ul>

<li><a href=book.ps>Postscript, English version</a> <li><a href=book.html>HTML, English version</a> <li><a href=book_ss.pdf>PDF, Spoken Sanskrit version</a> </ul>

Качество источника, заданное в заголовке Alternates, представляется значением качества, или qvalue (см. главу 7, раздел 7.9), которое указывает на качество альтернативного представления. В приведенном выше примере принято, что версия книги в формате Word имеет значение качества, меньшее 1 (0.5), т.е. уступает представлениям в форматах HTML, PostScript и PDF.

Заголовок Vary (см. главу 7, раздел 7.3.3) используется для указания, что выбор кэшированного ресурса должен осуществляться с учетом списка заголовков. Значение поля, следующее за negotiate, указывает, какой атрибут будет использоваться прокси-серверами для выбора варианта содержания. В примере таким значением является accept-language, которое указывает, что серверам следует использовать язык ресурса. Другими возможными атрибутами являются: тип ресурса, набор символов и набор характеристик, которые влияют на качество варианта, такие как цветовое разрешение, ширина или высота страницы.

Агент пользователя НТТР/1.1, который не поддерживает TCN, может отображать тело содержимого. Если приведенный выше ответ содержит заголовок Location, агент пользователя может переадресовать пользователя в указанное место. Агент пользователя НТТР/1.1, который поддерживает TCN, должен уметь автоматически извлекать и отображать приемлемый вариант после того, как такой вариант выбран. Если ни один из указанных вариантов неприемлем, агент пользователя может отобразить сообщение об ошибке.

Хотя несколько серверных реализаций [Hol] уже имеется, на стороне клиента таких реализаций пока нет, что не позволяет говорить о распространении TCN в Web. В IETF была сформирована рабочая группа Content Negotiation Working Group для исследования проблем выбора вариантов содержания как внутри протокола HTTP, так и вне его.

 

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100