Конкретный документ называется ресурсом. Когда клиент хочет получить ресурс, он запрашивает его через URL. Сервер использует этот URL для выбора одного из доступных вариантов — каждый вариант называется представлением — и возвращает клиенту конкретное представление. Как общий ресурс, так и каждое из представлений имеет конкретный URL. Переговоры о представлении контента определяют, как выбирается конкретное представление при обращении к ресурсу. Существует несколько способов переговоров между клиентом и сервером.

Лучшее подходящее представление определяется одним из двух механизмов:

• Специальные HTTP-заголовки со стороны клиента (переговоры, управляемые сервером или проактивные переговоры), что является стандартным способом переговоров о конкретном типе ресурса.
• Код ответа HTTP сервера 300 (Несколько вариантов) или 406 (Неприемлемо), 415 (Неподдерживаемый тип носителя) коды ответа HTTP (переговоры, управляемые агентом или реактивные переговоры), которые используются как механизмы резервного копирования.

На протяжении многих лет предлагались другие предложения по переговорам о представлении контента, такие как прозрачные переговоры о представлении контента и заголовок Alternates. Они не получили широкого распространения и были оставлены.

В переговорах о представлении контента, управляемых сервером, или проактивных переговорах, браузер (или любой другой пользовательский агент) отправляет несколько HTTP-заголовков вместе с URL. Эти заголовки описывают предпочтения пользователя. Сервер использует их как подсказки, а внутренний алгоритм выбирает лучший контент для отправки клиенту. Если он не может предоставить подходящий ресурс, он может ответить кодом 406 (Неприемлемо) или 415 (Неподдерживаемый тип носителя) и установить заголовки для типов носителей, которые он поддерживает (например, используя Accept-Post или Accept-Patch для запросов POST и PATCH соответственно). Алгоритм специфичен для сервера и не определен в стандарте. См. алгоритм переговоров Apache.

Стандарт HTTP/1.1 определяет список стандартных заголовков, которые запускают переговоры, управляемые сервером (например, Accept, Accept-Encoding и Accept-Language). Хотя User-Agent не входит в этот список, он иногда также используется для отправки конкретного представления запрашиваемого ресурса. Однако это не всегда считается хорошей практикой. Сервер использует заголовок Vary, чтобы указать, какие заголовки он фактически использовал для переговоров о представлении контента (или, точнее, соответствующие заголовки запроса), чтобы кэши могли работать оптимально.

В дополнение к этим, существует экспериментальное предложение добавить больше заголовков в список доступных заголовков, называемых подсказками клиента. Подсказки клиента рекламируют тип устройства, на котором работает пользовательский агент (например, настольный компьютер или мобильное устройство).

Даже если переговоры о представлении контента, управляемые сервером, являются наиболее распространённым способом согласования конкретного представления ресурса, они имеют несколько недостатков:

• Сервер не имеет полного знания о браузере. Даже с расширением Клиентские подсказки у него нет полного представления о возможностях браузера. В отличие от реактивных переговоров, где выбор делает клиент, выбор сервера всегда несколько произвольный.
• Информация от клиента довольно объёмная (сжатие заголовков HTTP/2 смягчает эту проблему) и представляет собой риск для конфиденциальности (отслеживание браузера по HTTP).
• Поскольку отправляется несколько представлений одного ресурса, общие кэши менее эффективны, а реализации сервера более сложные.

Заголовок Accept перечисляет типы MIME медиа-ресурсов, которые агент готов обработать. Это список типов MIME, разделённых запятыми, каждый из которых сочетается с коэффициентом качества, параметром, указывающим относительную степень предпочтения между различными типами MIME.

Заголовок Accept определяется браузером или любым другим пользовательским агентом и может варьироваться в зависимости от контекста. Например, при загрузке HTML-страницы или изображения, видео или скрипта. Он отличается при загрузке документа, введённого в адресную строку, или элемента, связанного через элемент <img>, <video> или <audio>. Браузеры могут использовать значение заголовка, которое они считают наиболее подходящим; доступен исчерпывающий список значений по умолчанию для распространённых браузеров.

Экспериментальный заголовок Accept-CH перечисляет данные конфигурации, которые сервер может использовать для выбора подходящего ответа. Допустимые значения:

Значение	Значение
Device-Memory	Указывает приблизительный объём оперативной памяти устройства. Это приближение, полученное путём округления до ближайшей степени двойки и деления этого числа на 1024. Например, 512 мегабайт будет отображаться как 0.5.
Viewport-Width	Указывает ширину области просмотра макета в пикселях CSS.
Width	Указывает ширину ресурса в физических пикселях (другими словами, внутренний размер изображения).

Заголовок Accept-CH-Lifetime используется со значением Device-Memory заголовка Accept-CH и указывает время, в течение которого устройство должно принять участие в совместном использовании оперативной памяти устройства с сервером. Значение указано в миллисекундах и является необязательным.

Заголовок Accept-Encoding определяет допустимое кодирование контента (поддерживаемые типы сжатия). Значение — это список с коэффициентами качества (например, br, gzip;q=0.8) который указывает приоритет значений кодирования. Значение по умолчанию identity имеет наименьший приоритет (если не указано иное).

Сжатие сообщений HTTP — один из важнейших способов повышения производительности веб-сайта. Оно уменьшает размер передаваемых данных и эффективнее использует доступную пропускную способность. Браузеры всегда отправляют этот заголовок, а сервер должен быть настроен на использование сжатия.

Заголовок Accept-Language используется для указания языковых предпочтений пользователя. Это список значений с коэффициентами качества (например, "de, en;q=0.7). Значение по умолчанию часто устанавливается в соответствии с языком графического интерфейса пользовательского агента, но большинство браузеров позволяют задавать различные языковые предпочтения.

Из-за увеличения энтропии, основанной на настройках, можно использовать изменённое значение для отслеживания пользователя. Не рекомендуется его изменять, а веб-сайт не должен полагаться на это значение как на отражение реальных намерений пользователя. Разработчикам веб-сайтов лучше избегать использования обнаружения языка через этот заголовок, так как это может привести к плохим пользовательским ощущениям.

• Они всегда должны предоставлять возможность переопределения языка, выбранного сервером, например, предоставляя языковое меню на сайте. Большинство пользовательских агентов предоставляют значение по умолчанию для заголовка Accept-Language, адаптированное к языку пользовательского интерфейса. Конечные пользователи часто не изменяют его, потому что либо не знают, как это сделать, либо не могут сделать это из-за среды их компьютера.
• После того, как пользователь переопределил язык, выбранный сервером, сайт больше не должен использовать обнаружение языка и должен придерживаться явно выбранного языка. Другими словами, только страницы входа на сайт должны использовать этот заголовок для выбора подходящего языка.

Заголовок User-Agent идентифицирует браузер, отправляющий запрос. Эта строка может содержать список разделенных пробелами токенов продукта и комментариев.

Токен продукта — это имя, за которым следует '/' и номер версии, например Firefox/4.0.1. Пользовательский агент может включать любое количество таких токенов. Комментарий — это необязательная строка, ограниченная скобками. Информация, предоставленная в комментарии, не стандартизирована, хотя несколько браузеров добавляют несколько токенов в него, разделенных ';'.

В отличие от предыдущих заголовков Accept-*, которые отправляются клиентом, заголовок HTTP Vary отправляется веб-сервером в ответе. Он указывает список заголовков, которые сервер использует во время фазы согласования контента, управляемой сервером. Заголовок Vary необходим для информирования кеша о критериях принятия решения, чтобы он мог его воспроизвести. Это позволяет кешу работать и гарантирует, что пользователю будет предоставлен правильный контент.

Специальное значение '*' означает, что согласование контента, управляемое сервером, также использует информацию, не передаваемую в заголовке, для выбора подходящего контента.

Заголовок Vary был добавлен в версии 1.1 HTTP и позволяет кешам работать должным образом. Для работы с согласованием контента, управляемым сервером, кеш должен знать, какие критерии сервер использовал для выбора передаваемого контента. Таким образом, кеш может воспроизвести алгоритм и сможет предоставлять приемлемый контент напрямую, без дополнительных запросов к серверу. Очевидно, что символ подстановки '*' предотвращает кэширование, так как кеш не может знать, какой элемент стоит за ним. Более подробную информацию см. в разделе Кэширование HTTP > Изменяющиеся ответы.

Переговоры, управляемые сервером, имеют несколько недостатков: они не масштабируются хорошо. В переговорах используется один заголовок на функцию. Если вы хотите использовать размер экрана, разрешение или другие параметры, вам нужно создать новый заголовок HTTP. Заголовки должны затем отправляться с каждым запросом. Это не проблема, если заголовков немного, но по мере увеличения их количества размер сообщения может в конечном итоге повлиять на производительность. Чем точнее отправляются заголовки, тем больше энтропии отправляется, что позволяет проводить больше отслеживаний HTTP и соответствующие проблемы с конфиденциальностью.

HTTP позволяет использовать другой тип переговоров: переговоры, управляемые агентом или реактивные переговоры. В этом случае, в случае неоднозначного запроса, сервер отправляет страницу, содержащую ссылки на доступные альтернативные ресурсы. Пользователю предлагаются ресурсы, и он выбирает нужный.

К сожалению, стандарт HTTP не определяет формат страницы для выбора между доступными ресурсами, что не позволяет автоматизировать этот процесс. Помимо возврата к переговорам, управляемым сервером, этот метод почти всегда используется с программированием, особенно с перенаправлением JavaScript: после проверки критериев переговоров скрипт выполняет перенаправление. Ещё одна проблема заключается в том, что для получения реального ресурса требуется ещё один запрос, замедляя доступ к ресурсу для пользователя.