如何解释空的HTTP Accept标头？

Question

HTTP/1.1 Accept请求标头在RFC 2616的第14.1节中指定.

它的语法是这样的:

   Accept         = "Accept" ":"
                    #( media-range [ accept-params ] )

#根据第2.1节,没有任何数字状态为零或更多.但是,第14.1节没有说明如何解释空标题.这与第14.2节相反,第14.2节谈到了,不仅使用了(一个或多个),而且指定了空标题的情况,这有点奇怪.处理请求标头的其他一些部分也特定于空值的特殊情况.AcceptAccept-Encoding1#Accept-Encoding

是否应该将空 Accept标题等同于不存在的 Accept标题？我错过了这方面的官方资源吗？

Answer 1

来自RFC2616 Sec4.2:

每个标题字段由一个名称后跟一个冒号(":")和字段值组成.

乍一看,这似乎会将指定空标头值的消息放入格式错误,不合规的类别中.但是,RFC2616 Sec2.1中概述的增强型BNF表单表明了这一点

"#element"允许任何数字,包括零

由于这是用于指定Accept标头值的声明,因此空值似乎是有效的.

解析空标题和标题只有空格可能会有问题,因为规范的以下方向:

字段内容不包括任何前导或尾随LWS:线性空白区域出现在字段值的第一个非空白字符之前或字段值的最后一个非空白字符之后.可以在不改变字段值的语义的情况下移除这种前导或尾随LWS.在解释字段值或向下游转发消息之前,可以用单个SP替换在字段内容之间发生的任何LWS.

恕我直言,发送一个空头是完全没有意义的.不应该这样做,解析器可能无法正确解析这些标头.传统上,想要在处理不兼容组件时规避此类限制的人已经指定了"伪空"值,如下所示:

X-MyCustomHeader: ""

如果您只是想验证标头字段是否作为某种形式的布尔开关发送,请考虑发送类似于上面的占位符值而不是空值.

更新

我想我不是很清楚直接回答这个问题:在一个空的Accept标题的情况下,你真的有两个选择:

• 发送406 Not Acceptable响应以通知客户端您没有为空的Accept值(duh)提供任何内容类型.

这是合理的,但RFC2616 Sec14.1不要求:

如果存在Accept头字段,并且如果服务器无法根据组合的Accept字段值发送可接受的响应,则服务器应该发送406(不可接受)响应.

• 或者,因为这不是必需的,并且用户不太可能不接受任何内容类型(否则,他们为什么要费心发送请求？)...我建议处理一个空Accept:值(如果消息拒绝不是'选项)与...相同Accept: */*.

Answer 2

根据http://tools.ietf.org/html/rfc7231#section-5.3.2:

没有任何Accept标头字段的请求意味着用户代理将接受任何媒体类型作为响应.

您应该将不存在的Accept标头视为*/*.