Apache: Согласование контента

RU EN

Пункт 16. Согласование контента

Apache HTTPD поддерживает согласование содержимого, как описано в спецификации HTTP/1.1. Он может выбрать наилучшее представление ресурса на основе настроек браузера для типа мультимедиа, языков, набора символов и кодировки. Он также реализует несколько функций, обеспечивающих более интеллектуальную обработку запросов от браузеров, которые отправляют неполную информацию о согласовании.

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

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

Ресурс может быть доступен в нескольких различных представлениях. Например, он может быть доступен на разных языках или разных типах носителей или в их комбинации. Один из способов выбрать наиболее подходящий вариант — предоставить пользователю индексную страницу и позволить ему выбирать. Однако часто сервер может выбирать автоматически. Это работает, потому что браузеры могут отправлять в составе каждого запроса информацию о том, какие представления они предпочитают. Например, браузер может указать, что хотел бы видеть информацию на французском языке, если это возможно, в противном случае подойдет английский. Браузеры указывают свои предпочтения заголовками в запросе. Чтобы запросить только французские представления, браузер должен отправить

Accept-Language: fr

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

В качестве примера более сложного запроса: этот браузер настроен на прием французского и английского языков, но предпочитает французский язык и принимает различные типы мультимедиа, предпочитая HTML, а не обычный текст или другие типы текста, и предпочитая GIF или JPEG другим типам мультимедиа. , но также разрешить любой другой тип носителя в качестве крайней меры:

Accept-Language: fr; q=1.0, en; q=0.5 Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

httpd поддерживает «управляемое сервером» согласование содержимого, как определено в спецификации HTTP/1.1. Он полностью поддерживает заголовки запросов Accept , Accept-Language , Accept-Charset и Accept-Encoding . httpd также поддерживает «прозрачное» согласование содержимого, которое представляет собой экспериментальный протокол согласования, определенный в RFC 2295 и RFC 2296. Он не предлагает поддержку «согласования функций», как определено в этих RFC.

Ресурс — это концептуальная сущность , определяемая URI (RFC 2396). HTTP-сервер, такой как Apache HTTP Server, обеспечивает доступ к представлениям ресурса (ресурсов) в своем пространстве имен, причем каждое представление в виде последовательности байтов с определенным типом носителя, набором символов, кодировкой и т. д. Каждый ресурс может быть связан с нулем, одним или более чем одним представлением в любой момент времени. Если доступно несколько представлений, ресурс называется оборотным , а каждое из его представлений называется вариантом . Способы, которыми меняются варианты оборотного ресурса, называются размерами переговоров .

Переговоры в httpd

Для согласования ресурса серверу необходимо предоставить информацию о каждом из вариантов. Это делается одним из двух способов:

Использование карты типов ( т. е . файла *.var ), которая явно называет файлы, содержащие варианты, или
Использование поиска «MultiViews», когда сервер выполняет неявное сопоставление с шаблоном имени файла и выбирает один из результатов.

Использование файла карты типов

Карта типов — это документ, связанный с именованным обработчиком type-map (или, для обратной совместимости со старыми конфигурациями httpd, MIME-type application/x-type-map ). Обратите внимание, что для использования этой функции в конфигурации должен быть установлен обработчик, определяющий суффикс файла как type-map ; это лучше всего сделать с

 Карта типов AddHandler .var

в файле конфигурации сервера.

Файлы карты типов должны иметь то же имя, что и ресурс, который они описывают, за которым следует расширение .var . В приведенных ниже примерах ресурс называется foo , поэтому файл сопоставления типов называется foo.var .

В этом файле должна быть запись для каждого доступного варианта; эти записи состоят из смежных строк заголовков в формате HTTP. Записи для разных вариантов разделяются пустыми строками. Пустые строки недопустимы в записи. Обычно файл карты начинается с записи для объединенного объекта в целом (хотя это не требуется, и если оно присутствует, оно будет проигнорировано). Пример файла карты показан ниже.

URI в этом файле относятся к расположению файла сопоставления типов. Обычно эти файлы располагаются в том же каталоге, что и файл сопоставления типов, но это не обязательно. Вы можете указать абсолютные или относительные URI для любого файла, расположенного на том же сервере, что и файл карты.

URI: foo URI: foo.en.html Content-type: text/html Content-language: en URI: foo.fr.de.html Content-type: text/html;charset=iso-8859-2 Content-language: fr, de

Также обратите внимание, что файл карты типов будет иметь приоритет над расширением имени файла, даже если включен режим Multiview. Если варианты имеют разное исходное качество, это может быть указано параметром «qs» для типа носителя, как на этом рисунке (доступно в формате JPEG, GIF или ASCII-art):

URI: foo URI: foo.jpeg Content-type: image/jpeg; qs=0.8 URI: foo.gif Content-type: image/gif; qs=0.5 URI: foo.txt Content-type: text/plain; qs=0.01

значения qs могут варьироваться в диапазоне от 0,000 до 1,000. Обратите внимание, что любой вариант со значением qs 0,000 никогда не будет выбран. Вариантам без значения параметра qs присваивается коэффициент qs, равный 1,0. Параметр qs указывает относительное «качество» этого варианта по сравнению с другими доступными вариантами, независимо от возможностей клиента. Например, файл JPEG обычно имеет более высокое исходное качество, чем файл ASCII, если он пытается представить фотографию. Однако, если представляемый ресурс является оригинальным изображением ASCII, то представление ASCII будет иметь более высокое качество исходного изображения, чем представление JPEG. Таким образом, значение qs специфично для данного варианта в зависимости от природы ресурса, который он представляет.

Полный список распознаваемых заголовков доступен в документации карты типов mod_negotiation.

Мультивиды

MultiViews является параметром для каждого каталога, что означает, что его можно установить с помощью Options директивы в файле <Directory> , <Location> или <Files> раздела в apache2.conf , или (если AllowOverride он установлен правильно) в .htaccess файлах. Обратите внимание, что Options All не устанавливает MultiViews ; вы должны спросить об этом по имени.

Эффект MultiViews следующий: если сервер получает запрос на /some/dir/foo , если он /some/dir включен MultiViews и /some/dir/foo не существует, то сервер читает каталог в поисках файлов с именем foo.* и эффективно подделывает карту типов, которая называет все эти файлы , назначая им те же типы мультимедиа и кодировки контента, которые были бы, если бы клиент запросил один из них по имени. Затем он выбирает наилучшее соответствие требованиям клиента.

MultiViews может также применяться к поиску файла, указанного в директиве DirectoryIndex , если сервер пытается проиндексировать каталог. Если в файлах конфигурации указано

 Индекс DirectoryIndex

тогда сервер выполнит арбитраж между index.html и, index.html3 если оба присутствуют. Если ни один из них не присутствует и index.cgi не существует, сервер запустит его.

Если один из найденных при чтении каталога файлов не имеет расширения, распознаваемого для mod_mime обозначения его Charset, Content-Type, Language или Encoding, то результат зависит от настройки директивы MultiViewsMatch . Эта директива определяет, могут ли обработчики, фильтры и другие типы расширений участвовать в согласовании MultiViews.

Методы переговоров

После того, как httpd получил список вариантов для данного ресурса либо из файла сопоставления типов, либо из имен файлов в каталоге, он вызывает один из двух методов, чтобы решить, какой из «лучших» вариантов следует вернуть, если таковой имеется. Нет необходимости знать какие-либо подробности того, как на самом деле происходит согласование, чтобы использовать функции согласования контента httpd. Однако остальная часть этого документа объясняет методы, используемые для тех, кто заинтересован.

Существует два метода переговоров:

В обычном случае используется серверное согласование с алгоритмом httpd . Алгоритм httpd более подробно описан ниже. Когда используется этот алгоритм, httpd иногда может «манипулировать» коэффициентом качества определенного измерения для достижения лучшего результата. Способы, которыми httpd может воздействовать на факторы качества, более подробно объясняются ниже.
Прозрачное согласование контента используется, когда браузер специально запрашивает это с помощью механизма, определенного в RFC 2295. Этот метод согласования дает браузеру полный контроль над выбором «наилучшего» варианта, поэтому результат зависит от конкретных алгоритмов, используемых браузером. В рамках прозрачного процесса согласования браузер может попросить httpd запустить «алгоритм выбора удаленного варианта», определенный в RFC 2296.

Размеры переговоров

Измерение	Примечания
Тип носителя	Браузер указывает предпочтения в `Accept` поле заголовка. Каждый элемент может иметь связанный коэффициент качества. Описание варианта также может иметь добротность (параметр «qs»).
Язык	Браузер указывает предпочтения в `Accept-Language` поле заголовка. Каждый элемент может иметь коэффициент качества. Варианты могут быть связаны ни с одним языком, с одним или несколькими языками.
Кодирование	Браузер указывает предпочтения в `Accept-Encoding` поле заголовка. Каждый элемент может иметь коэффициент качества.
Набор символов	Браузер указывает предпочтения в `Accept-Charset` поле заголовка. Каждый элемент может иметь коэффициент качества. Варианты могут указывать кодировку как параметр типа носителя.

Алгоритм переговоров httpd

httpd может использовать следующий алгоритм для выбора «лучшего» варианта (если он есть) для возврата в браузер. Этот алгоритм не подлежит дальнейшей настройке. Он работает следующим образом:

Во-первых, для каждого измерения переговоров проверьте соответствующее поле заголовка Accept* и назначьте качество каждому варианту. Если заголовок Accept* для какого-либо измерения подразумевает, что этот вариант неприемлем, удалите его. Если вариантов не осталось, перейдите к шагу 4.
Выберите «лучший» вариант методом исключения. Каждый из следующих тестов применяется по порядку. Любые варианты, не выбранные в каждом тесте, исключаются. После каждого теста, если остается только один вариант, выберите его как наиболее подходящий и перейдите к шагу 3. Если осталось более одного варианта, перейдите к следующему тесту.
1. Умножьте коэффициент качества из Accept заголовка на коэффициент качества источника для этого типа носителя вариантов и выберите варианты с самым высоким значением.
2. Выберите варианты с наивысшим коэффициентом качества языка.
3. Выберите варианты с лучшим языковым соответствием, используя либо порядок языков в заголовке Accept-Language (если есть), либо порядок языков в LanguagePriority директиве (если есть).
4. Выберите варианты с самым высоким параметром мультимедиа «уровень» (используется для указания версии типов мультимедиа text/html).
5. Выберите варианты с лучшими параметрами мультимедиа набора символов, как указано в Accept-Charset строке заголовка. Кодировка ISO-8859-1 приемлема, если явно не исключена. Предполагается, что варианты с text/* типом носителя, не связанные явно с конкретной кодировкой, соответствуют стандарту ISO-8859-1.
6. Выберите те варианты, которые имеют связанные параметры мультимедиа набора символов, отличные от ISO -8859-1. Если таких вариантов нет, вместо этого выберите все варианты.
7. Выберите варианты с лучшей кодировкой. Если есть варианты с кодировкой, приемлемой для пользовательского агента, выберите только эти варианты. В противном случае, если есть сочетание кодированных и некодированных вариантов, выберите только некодированные варианты. Если все варианты закодированы или все варианты не закодированы, выберите все варианты.
8. Выберите варианты с наименьшей длиной контента.
9. Выберите первый вариант из оставшихся. Это будет либо первый список в файле карты типов, либо при чтении вариантов из каталога тот, имя файла которого стоит первым при сортировке с использованием порядка кодов ASCII.
Теперь алгоритм выбрал один «лучший» вариант, поэтому верните его в качестве ответа. В заголовке ответа HTTP Vary указываются размеры согласования (браузеры и кэши могут использовать эту информацию при кэшировании ресурса). Конец.
Попасть сюда означает, что не выбран ни один вариант (поскольку ни один из них не приемлем для браузера). Вернуть статус 406 (что означает «Нет приемлемого представления») с телом ответа, состоящим из HTML-документа со списком доступных вариантов. Также установите заголовок HTTP Vary , чтобы указать размеры отклонения.

Игра с ценностями качества

httpd иногда изменяет значения качества по сравнению с тем, что можно было бы ожидать при строгой интерпретации приведенного выше алгоритма согласования httpd. Это необходимо для получения лучшего результата от алгоритма для браузеров, которые не отправляют полную или точную информацию. Некоторые из самых популярных браузеров отправляют Accept информацию заголовка, которая в противном случае во многих случаях привела бы к выбору неправильного варианта. Если браузер отправляет полную и правильную информацию, эти скрипты не будут применяться.

Типы носителей и подстановочные знаки

Заголовок Accept: запроса указывает предпочтения для типов мультимедиа. Он также может включать подстановочные типы мультимедиа, такие как «image/*» или «*/*», где * соответствует любой строке. Итак, запрос, включающий:

Accept: image/*, */*

будет означать, что допустим любой тип, начинающийся с «image/», как и любой другой тип. Некоторые браузеры регулярно отправляют подстановочные знаки в дополнение к явным типам, которые они могут обрабатывать. Например:

Accept: text/html, text/plain, image/gif, image/jpeg, */*

Цель этого состоит в том, чтобы указать, что явно перечисленные типы являются предпочтительными, но если доступно другое представление, это тоже нормально. Используя явные значения качества, браузер действительно хочет что-то вроде:

Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01

Явные типы не имеют коэффициента качества, поэтому по умолчанию они имеют приоритет 1,0 (самый высокий). Подстановочный знак */* имеет низкий приоритет 0,01, поэтому другие типы будут возвращены только в том случае, если ни один вариант не соответствует явно указанному типу.

Если заголовок вообще не Accept: содержит коэффициентов q, httpd устанавливает значение q "*/*", если оно присутствует, равным 0,01, чтобы эмулировать желаемое поведение. Он также устанавливает значение q подстановочных знаков формата «тип/*» равным 0,02 (поэтому они предпочтительнее совпадений с «*/*». Если какой-либо тип носителя в заголовке содержит фактор aq, эти специальные значения не применяются, поэтому запросы от браузеров, которые отправляют явную информацию, чтобы начать работу, как и ожидалось. Accept:

Исключения при согласовании языка

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

Когда клиент запрашивает страницу на вашем сервере, но сервер не может найти ни одной страницы, которая соответствует отправленной Accept-language браузером, сервер вернет клиенту ответ «Нет приемлемого варианта» или «Несколько вариантов». Чтобы избежать этих сообщений об ошибках, можно настроить httpd для игнорирования Accept-language в этих случаях и предоставления документа, который явно не соответствует запросу клиента. Директива ForceLanguagePriority может использоваться для переопределения одного или обоих этих сообщений об ошибках и замены суждения сервера в форме директивы LanguagePriority .

Сервер также попытается сопоставить языковые подмножества, если не будет найдено никакого другого совпадения. Например, если клиент запрашивает документы на en-GB британском английском языке, стандарт HTTP/1.1 обычно не разрешает серверу сопоставлять это с документом, помеченным просто как en . (Обратите внимание, что почти наверняка ошибка конфигурации заключается в том, чтобы включить ее en-GB , а не указать en в Accept-Language заголовке, поскольку очень маловероятно, что читатель понимает британский английский, но не понимает английский в целом. К сожалению, многие текущие клиенты имеют настройки по умолчанию, похожие на эту .) Однако, если никакое другое совпадение языка невозможно и сервер собирается вернуть ошибку «Нет приемлемых вариантов» или вернуться к LanguagePriority , сервер проигнорирует спецификацию подмножества и сопоставит en-GB с en документами. Неявно httpd добавит родительский язык в список допустимых языков клиента с очень низким значением качества. Но учтите, что если клиент запрашивает "en-GB; q=0.9, fr; q=0.8", а на сервере есть документы с обозначениями "en" и "fr", то будет возвращен документ "fr". Это необходимо для обеспечения соответствия спецификации HTTP/1.1 и эффективной работы с правильно настроенными клиентами.

Для поддержки передовых методов (таких как файлы cookie или специальные URL-пути) для определения предпочтительного языка пользователя, поскольку httpd 2.0.47 mod_negotiation распознает переменную среды prefer-language . Если он существует и содержит соответствующий языковой тег, mod_negotiation будет предпринята попытка выбрать соответствующий вариант. Если такого варианта нет, применяется обычный переговорный процесс.

Пример

 SetEnvIf Cookie "language=(.+)" предпочитаемый-язык=$1
Заголовок добавляет Vary cookie

Расширения для прозрачного согласования контента

httpd расширяет протокол согласования прозрачного содержимого (RFC 2295) следующим образом. Новый {encoding ..} элемент используется в списках вариантов для маркировки вариантов, которые доступны только с определенной кодировкой содержимого. Реализация алгоритма RVSA/1.0 (RFC 2296) расширена, чтобы распознавать закодированные варианты в списке и использовать их в качестве вариантов-кандидатов, когда их кодировки приемлемы в соответствии с заголовком запроса Accept-Encoding . Реализация RVSA/1.0 не округляет вычисленные коэффициенты качества до 5 знаков после запятой перед выбором наилучшего варианта.

Примечание о гиперссылках и соглашениях об именах

Если вы используете согласование языка, вы можете выбирать между различными соглашениями об именах, потому что файлы могут иметь более одного расширения, а порядок расширений обычно не имеет значения (подробности см. в документации по mod_mime).

Типичный файл имеет расширение типа MIME ( например , html ), может быть расширение кодировки ( например , , gz ) и, конечно, языковое расширение ( например , en ), когда у нас есть разные языковые варианты этого файла.

Примеры:

foo.en.html
foo.html.en
foo.en.html.gz

Вот еще несколько примеров имен файлов вместе с действительными и недействительными гиперссылками:

Имя файла	Действительная гиперссылка	Недействительная гиперссылка
foo.html.en	foo foo.html	-
foo.en.html	фу	foo.html
foo.html.en.gz	foo foo.html	foo.gz foo.html.gz
foo.en.html.gz	фу	foo.html foo.html.gz foo.gz
foo.gz.html.en	foo foo.gz foo.gz.html	foo.html
foo.html.gz.en	foo foo.html foo.html.gz	foo.gz

Глядя на приведенную выше таблицу, вы заметите, что всегда можно использовать имя без каких-либо расширений в гиперссылке ( например , , foo ). Преимущество в том, что вы можете скрыть фактический тип документа, например. файл и может изменить его позже, например , с html на shtml или cgi без изменения каких-либо гиперссылок.

Если вы хотите продолжать использовать MIME-тип в своих гиперссылках ( например foo.html ), расширение языка (включая расширение кодировки, если оно есть) должно быть справа от расширения MIME-типа ( например , foo.html.en ).

Примечание о кэшировании

Когда кэш сохраняет представление, он связывает его с URL-адресом запроса. В следующий раз, когда будет запрошен этот URL-адрес, кеш может использовать сохраненное представление. Но если ресурс является согласованным на сервере, это может привести к кэшированию только первого запрошенного варианта, а последующие обращения к кэшу могут возвращать неверный ответ. Чтобы предотвратить это, httpd обычно помечает все ответы, возвращаемые после согласования содержимого, как некэшируемые клиентами HTTP/1.0. httpd также поддерживает функции протокола HTTP/1.1, позволяющие кэшировать согласованные ответы.

Для запросов, поступающих от клиента, совместимого с HTTP/1.0 (либо из браузера, либо из кэша), директива CacheNegotiatedDocs может использоваться для разрешения кэширования ответов, которые были предметом согласования. Эта директива может быть задана в конфигурации сервера или виртуального хоста и не имеет аргументов. Это не влияет на запросы от клиентов HTTP/1.1.

Для клиентов HTTP/1.1 httpd отправляет Vary заголовок ответа HTTP, чтобы указать параметры согласования для ответа. Кэши могут использовать эту информацию, чтобы определить, может ли последующий запрос быть обслужен из локальной копии. Чтобы кэш использовал локальную копию независимо от параметров согласования, задайте force-no-vary переменную среды.