Accept и Accept-Charset - что лучше?

Question

В HTTP вы можете указать в запросе, что ваш клиент может принимать определенный контент в ответах, используя заголовок accept со значениями, такими как application/xml.Спецификация типа контента позволяет вам включать параметры в тип контента, такие как charset=utf-8, указывая, что вы можете принимать контент с указанным набором символов.

Существует также заголовок accept-charset, который определяеткодировки символов, которые принимаются клиентом.

Если указаны оба заголовка, а заголовок accept содержит типы содержимого с параметром charset, который должен рассматриваться сервером как верхний заголовок?

Например:

Accept: application/xml; q=1,
        text/plain; charset=ISO-8859-1; q=0.8
Accept-Charset: UTF-8

Я отправил несколько примеров запросов на различные серверы, используя Fiddler, чтобы проверить, как они отвечают:

Примеры

W3

Запрос

GET http://www.w3.org/ HTTP/1.1
Host: www.w3.org
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1

Ответ

Content-Type: text/html; charset=utf-8

Google

Запрос

GET http://www.google.co.uk/ HTTP/1.1
Host: www.google.co.uk
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1

Ответ

Content-Type: text/html; charset=ISO-8859-1

StackOverflow

Запрос

GET http://stackoverflow.com/ HTTP/1.1
Host: stackoverflow.com
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1

Ответ

Content-Type: text/html; charset=utf-8

Microsoft

Запрос

GET http://www.microsoft.com/ HTTP/1.1
Host: www.microsoft.com
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1

Ответ

Content-Type: text/html

Есть ДоуПохоже, нет никакого консенсуса относительно ожидаемого поведения.Я пытаюсь выглядеть удивленным.

Answer 1

Хотя вы можете установить тип носителя в заголовке Accept, определение параметра charset для этого типа носителя не определено нигде в RFC 2616 (но это не запрещено).

Поэтому, если вы собираетесь внедрить сервер, совместимый с HTTP 1.1, вы сначала должны искать заголовок Accept-charset, а затем искать свои собственные параметры в заголовке Accept.

Answer 2

Чтение RFC 2616 Раздел 14.1 и 14.2.Заголовок Accept не позволяет указывать charset.Вместо этого вы должны использовать заголовок Accept-Charset.

Answer 3

Во-первых, заголовки Accept могут принимать параметры, см. https://tools.ietf.org/html/rfc7231#section-5.3.2

Все текстовые / * MIME-типы могут принимать параметр charset.http://www.iana.org/assignments/media-types/media-types.xhtml#text

Заголовок Accept-Charset позволяет агенту пользователя указывать поддерживаемые им наборы символов.

Если заголовок Accept-Charset не существует, пользовательский агент должен будет указать каждый параметр charset для каждого text / * типа носителя, который он принял, например

Accept: text/html;charset=US-ASCII, text/html;charset=UTF-8, text/plain;charset=US-ASCII, text/plain;charset=UTF-8

Answer 4

RFC 7231 раздел 5.3.2 (Accept) четко заявляет:

За каждым медиа-диапазоном может следовать ноль или более применимых медиа параметры типа (например, кодировка)

Таким образом, параметр charset для каждого типа контента разрешен. Теоретически клиент может принять, например, text/html только в UTF-8 и text/plain только в US-ASCII.

Но обычно имеет смысл указать возможные кодировки в заголовке Accept-Charset , поскольку это относится ко всем типам, упомянутым в заголовке Accept.

Если кодировки этих заголовков не перекрываются, сервер может отправить статус 406 Not Acceptable.

Однако по разным причинам я не ожидал необычного перекрестного сопоставления с сервером. Это сделает серверный код более сложным (и, следовательно, более подверженным ошибкам), в то время как на практике клиент будет редко отправлять такие запросы. Также в настоящее время я ожидаю, что все, что на стороне сервера использует UTF-8 и отправлено как есть, поэтому не о чем договариваться.

Answer 5

Я не думаю, что это имеет значение. Клиент делает что-то глупое; для этого не требуется совместимость: -)