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

Если существует единственное представление ресурса, то для запроса такого ресурса Можно использовать простое сообщение-запрос 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 [Sec95]. Поскольку к моменту завершения документа RFC 1945, описывающего НТТР/1.0, копсепсус не был достигнут, дискуссия, относящаяся к пяти заголовкам запросов (Accept, Accept- Charset, Accept-Encoding, Accept-Language и Content-Language) была вынесена в приложение. В НТТР/1.1 не только оформлены результаты этой дискуссии о согласовании содержания, по и предложены два различных типа согласования:

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

•          Управляемое сервером. При управляемом сервером согласовании содержания сервер выбирает представление, основываясь на том, чем располагает сервер, на заголовках сообщения-запроса или на информации о клиенте, например, на его IР-адресе.

Задержка с реализацией общего для множества клиентов и серверов механизма согласования привела к отделению этих усилий от работы над спецификацией 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 0K Content-Length: 23819 Content-Language: fr-BE

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

Сервер-источник решил выбрать вариант ресурса на бельгийском французском языке, как это указано в заголовке Content-Language. Заголовок содержимого Content-Language указывает на естественный язык тела содержания и, следовательно, на тот язык, который был выбран получателем. Если содержание представлено на различных естественных языках, то этот заголовок является хорошим способом их различить. Тем не менее, в заголовке может быть перечислено несколько языков, если содержимое может восприниматься более широкой аудиторией. Вот пример использования заголовка Content-Language с несколькими языками

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

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

Агенты пользователя могут выражать свои предпочтения в заголовке в терминах, приемлемых типов содержания, по это обычно не имеет смысла, если сервер-источник не имеет возможности предоставить содержание в нужной форме. Агенты пользователя и клиенты могут согласовывать и другие аспекты, например кодировку, по единственным арбитром в согласованиях, связанных с содержанием, является Web-cepBep.

НТТР/1.1 разрешает серверу иметь свой собственный алгоритм генерации списка форматов и затем использовать информацию, представленную в заголовках запроса для пастройки ответа. Одной из побудительных причин для сервера посылать «наилучший» ответ связан с тем, чтобы избежать получения от клиента запро- ca на другой вариант содержания. Если запрашиваемый формат отсутствует, сервер может вернуть ответ 406 Not Acceptable. Код 406 Not Acceptable был введен для реализации управляемого агентом согласования. Сервер также включает информацию о различных свойствах ресурса так, чтобы отправитель запроса мог выбрать из числа доступных вариантов. Оборотной стороной ответа 406 Not Acceptable является дополнительный запрос, который необходим, чтобы получить приемлемый вариант из списка. Если сервер располагает всего одним вариантом, тогда надо дать ему возможность вернуть содержание, проигнорировав заголовок Accept. Спецификация считает, что предпочтительнее вернуть вариант, отличный от тех, которые перечислены как приемлемые, чем ответ 406 Not Acceptable.

Агенту пользователя сложно передать исходному серверу алгоритм выбора в запросе, поэтому лучшим местом для алгоритма выбора является Web-сервер. Конфигурационный файл сервера является подходящим местом для определения алгоритма выбора. Иначе говоря, сервер поддерживает алгоритм, который определяет лучший вариант ответа. Однако управляемого сервером согласования бывает достаточно не всегда. Уверенность, что areirr пользователя располагает выбором пользователя из перечня вариантов, приводит к тому, что сервер не будег способен выполнить эту задачу автоматически.

Код ответа 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. В этом примере сервер может посылать ответ в одном из указанных форматов или в своем собственном формате. Если клиент вместо этого задал бы

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

тогда сервер имеет ограниченный выбор послать ответ в одном из трех форматов (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, работа над этим продолжается независимо [HM98]. Прозрачное согласование содержания обсуждается более подробно в главе 15 (раздел 15.5.1).

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