Question

在HTTP中，您可以在请求中指定您的客户端可以使用accept标头接受响应中的特定内容，其值为application/xml。内容类型规范允许您在内容类型中包含参数，例如charset=utf-8，表示您可以接受具有指定字符集的内容。

还有accept-charset标头，它指定客户接受的字符编码。

如果指定了两个标头且accept标头包含带有charset参数的内容类型，那么服务器应该将其视为上级标头？

e.g：

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

谷歌

请求

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

微软

请求

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标头中设置媒体类型，但RFC 2616中的任何位置都未定义该媒体类型的charset参数定义（但不禁止）。

因此，如果您要实现符合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

Accept-Charset标头允许用户代理指定它支持的字符集。

如果Accept-Charset标头不存在，则用户代理必须为其接受的每个 text / *媒体类型指定每个 charset参数，例如< / p>

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

Answer 4

每个媒体范围后可能跟有零个或更多个适用的媒体类型参数（例如，字符集）

因此，每个内容类型的字符集参数都是允许的。从理论上讲，客户只能接受text/html中的UTF-8和仅text/plain中的US-ASCII。

但是通常更有意义的是在Accept-Charset header中声明可能的字符集，因为这适用于Accept标头中提到的所有类型。

如果这些标头的字符集不重叠，则服务器可以发送状态406 Not Acceptable。

但是，出于各种原因，我不希望服务器出现花哨的交叉匹配。这将使服务器代码更复杂（因此更容易出错），而实际上，客户端将rarely发送此类请求。如今，我也希望服务器端的所有内容都使用UTF-8并按原样发送，因此无需进行任何协商。

Answer 5

我认为这不重要。客户端正在做一些愚蠢的事情;不需要具有互操作性： - ）