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

Согласование содержимого со стороны клиента

Заголовок запроса Accept, наряду с другими заголовками согласования содержимого, появился еще в протоколе HTTP/1.0 Тогда значение этого заголовка задавалось парами "тип/подтип", перечисленными через запятую, где тип — это тип содержимого, а подтип — это уточнение типа.

Accept: text/plain, text/html, image/jpg, image/gif, audio/*

При этом как тип, так и подтип можно было задать множеством типов при помощи символа звездочки "*". Заголовок Accept: */* означал, что клиент готов принять любой тип содержимого.

В протоколе HTTP/1.1 заголовок Accept получил дальнейшее развитие. Список предпочтительных для клиента типов содержимого теперь может быть снабжен дополнительными параметрами для каждого типа, входящего в список. Если типы в списке отделяются друг от друга запятыми, то параметры типа отделяются от самого типа и друг от друга точкой с запятой, а имя параметра отделяется от значения параметра символом "=": тип/подтип; параметр=значение, тип/подтип; параметр=значение; параметр=значение, и т.д. В спецификации RFC 2616 определен только один параметр типа содержимого: q — оценка качества (qvalue). Разработчиками приложений могут быть введены и другие параметры в качестве расширения протокола.

Оценка качества — это число от 0 до 1, определяющее степень предпочтения клиентом того или иного типа содержимого. Более предпочтительные типы помечаются более высокой оценкой качества. Если оценка качества типа отсутствует, то по умолчанию ему ставится наивысшая оценка 1.

При рассмотрении типов, имеющих одинаковые оценки качества, наиболее приоритетными будут те, которые более конкретизированы.

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
	 text/html;level=2;q=0.4, */*;q=0.5

Примечание: параметр level введен для демонстрации более конкретизированного типа и не выполняет каких либо функций. На его месте с тем же успехом может быть параметр с любым другим именем.

В данном случае с учетом, в первую очередь, оценки качества и, во вторую, большей конкретизации типа порядок рассмотрения наиболее приоритетных типов будет следующим:

1. text/html;level=1 [q=1]
2. text/html;level=3 (как пример типа попадающий в множество text/html) [q=0.7]
3. text/html [q=0.7]
4. image/jpg (как пример типа попадающий в множество */*) [q=0.5]
5. text/html;level=2 [q=0.4]
6. text/plain (как пример типа попадающий в множество text/*) [q=0.3]

Согласование содержимого со стороны сервера

Концепция согласования содержимого со стороны сервера появилась только в протоколе HTTP/1.1
Запрос клиента предшествует ответу сервера, поэтому целесообразно стратегию согласования содержимого начинать с предпочтений клиента. Если же сервер определяет, что он не может предложить клиенту ни один из указанных им типов содержимого, он должен (уровень SHOULD) послать ему ответ с кодом состояния 406 Not Acceptable, а в заголовке ответа Content-Type привести список тех типов, которые он может предложить.

HTTP/1.1 406 Not Acceptable
Content-Type: text/html, text/xml

Если же на сервере ресурс представлен всего одним типом содержимого, то вместо ответа 406 Not Acceptable спецификация рекомендует вернуть ресурс, игнорируя заголовок Accept.