Согласование контента относится к механизмам, определенным как часть HTTP , которые позволяют обслуживать различные версии документа (или, в более общем смысле, представления ресурса) по одному и тому же URI , так что пользовательские агенты могут указать, какая версия лучше всего соответствует их возможностям. Одним из классических применений этого механизма является обслуживание изображения в формате GIF или PNG , так что браузер, который не может отображать изображения PNG (например, MS Internet Explorer 4), будет обслуживать версию GIF.
Ресурс может быть доступен в нескольких различных представлениях; например, он может быть доступен на разных языках или в разных типах носителей. Один из способов выбора наиболее подходящего варианта — предоставить пользователю страницу индекса и позволить ему выбрать наиболее подходящий вариант; однако часто можно автоматизировать выбор на основе некоторых критериев выбора.
HTTP предоставляет несколько различных механизмов согласования контента, включая: управляемый сервером (или проактивный), управляемый агентом (или реактивный), прозрачный и/или их гибридные комбинации.
Серверное или проактивное согласование контента выполняется алгоритмами на сервере, которые выбирают среди возможных вариантов представления. Обычно это выполняется на основе критериев приемки, предоставляемых пользовательским агентом.
Подводя итог, как это работает, когда пользовательский агент отправляет запрос на сервер, пользовательский агент сообщает серверу, какие типы медиа или другие аспекты представления контента он понимает, с оценками того, насколько хорошо он их понимает. Точнее, пользовательский агент предоставляет заголовки HTTP , в которых перечислены приемлемые аспекты ресурса и факторы качества для них. Затем сервер может предоставить версию ресурса, которая лучше всего соответствует потребностям пользовательского агента.
Например, браузер может указать, что ему нужна информация на немецком языке, установив следующее Accept-Language:
Accept-Language: de
Вместо этого браузер может указать, что предпочтительнее немецкий язык, если это возможно, но английский язык также приемлем, установив:
Accept-Language: de; q=1.0, en; q=0.5
При этом коэффициент качества «q» для немецкого языка выше, чем для английского.
Несколько заголовков HTTP часто поставляются вместе для формата контента или, в частности, типа носителя, языка и нескольких других аспектов ресурса. В дополнение к обычно используемому Acceptзаголовку для типа носителя, Accept-Languageзаголовку для согласования языка, RFC 7231 также описывает Accept-Charset& Accept-Encodingsдля кодировок символов и кодировок контента (сжатия) соответственно.
Примером более сложного запроса является случай, когда браузер отправляет заголовки о языке, указывающие, что немецкий язык предпочтительнее, но английский язык приемлем, как указано выше, и что в отношении форматов HTML ( text/html) предпочтительнее других типов текста ( text/*), изображения GIF ( image/gif) или JPEG ( image/jpg) предпочтительнее других форматов изображений ( image/*), но любой другой тип носителя ( */*) принимается в качестве крайней меры:
Accept-Language: de ; 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В дополнение к аспектам согласования контента на сервере по типу контента и языку , указанным в RFC 7231, существуют расширения, определяющие другие аспекты согласования контента, такие как Memento , которое описывает использование заголовка Accept-Datetimeдля получения версии представления ресурса в определенные моменты времени [1], и Согласование контента по профилю IETF/W3C [2] , которое описывает использование Accept-Profileзаголовка для получения представлений ресурсов, соответствующих профилям данных.
Ни RFC 7231, ни более поздние связанные спецификации, такие как Content Negotiation by Profile [2], не определяют, как разрешать компромиссы в случаях, когда разные заголовки указывают противоречивые требования, например, как в приведенном выше примере, при выборе между HTML-страницей на английском языке и GIF-изображением на немецком языке.
Агент-управляемое или реактивное согласование контента выполняется алгоритмами в пользовательском агенте, которые выбирают среди возможных вариантов представлений. Это обычно выполняется на основе предоставленного сервером списка представлений и метаданных о них.
Подводя итог, как это работает, когда пользовательский агент отправляет запрос на сервер, сервер сообщает пользовательскому агенту, какие представления у него есть в наличии, а также любые метаданные, которые у него есть о каждом представлении (например, тип контента, качество, язык и т. д.). Затем пользовательский агент повторно отправляет запрос на определенный URL для выбранного представления. Это может быть автоматически выбрано пользовательским агентом или пользовательский агент может предоставить пользователю выбор, и пользователь может напрямую выбрать его. Точнее, сервер отвечает либо 300 Multiple Choices, либо 406 Not Acceptable (когда предоставлены критерии принятия пользовательского агента, управляемые сервером, но сервер не может автоматически сделать выбор). К сожалению, HTTP оставляет формат списка представлений и метаданных вместе с механизмами выбора неопределенными.