HTTP {1.1 Accept
请求标头在RFC 2616, section 14.1中指定。
它的语法是这样的:
Accept = "Accept" ":"
#( media-range [ accept-params ] )
根据{{3}}, #
没有任何数字状态零或更多。但是,第14.1节没有对如何解释空Accept
标头做出任何声明。这与section 2.1形成鲜明对比,section 14.2讨论的是Accept-Encoding
,其中不仅使用了1#
(一个或多个),还有一个空的情况指定了Accept-Encoding
标头,这有点奇怪。处理请求标头的其他一些部分也特定于空值的特殊情况。
是否应该将空 Accept
标头等同于不存在的 Accept
标头?我错过了这方面的官方资源吗?
答案 0 :(得分:22)
每个标题字段由名称后跟冒号(“:”)和字段值组成。
乍一看,这似乎会将指定空标题值的消息放入格式错误,不合规的类别中。但是,RFC2616 Sec2.1中列出的增强型BNF表单表示
“#element”允许任何数字,包括零
由于这是用于指定Accept标头值的声明,因此空值似乎有效。
解析空标题和标题除了空白之外什么都没有问题,因为规范的方向如下:
恕我直言,发送一个空头是完全没有意义的。不应该这样做,解析器可能无法正确解析这些标头。传统上,想要在处理不合规组件时规避此类限制的人已经指定了“伪空”值,如下所示:字段内容不包括任何前导或尾随LWS:线性 在第一个非空白字符之前出现的空格 字段值或在最后一个非空白字符之后 域值。可以在没有的情况下移除这种前导或尾随LWS 改变字段值的语义。发生在之间的任何LWS field-content可以在解释之前用单个SP替换 字段值或向下游转发消息。
X-MyCustomHeader: ""
如果您只想验证标头字段是否作为某种形式的布尔开关发送,请考虑发送上述占位符值而不是空值。
<强>更新强>
我想我在直接回答这个问题时并不是很清楚:在一个空的Accept标题的情况下你真的有两个选择:
406 Not Acceptable
响应,通知客户您没有为空接受值(duh)提供任何内容类型。这是合理的,但不是RFC2616 Sec14.1所要求的:
如果存在Accept头字段,并且服务器无法发送 根据组合的Accept字段可接受的响应 值,那么服务器应该发送一个406(不可接受的)响应。
Accept:
值(如果邮件拒绝不是一个选项)与Accept: */*
相同。答案 1 :(得分:5)
根据http://tools.ietf.org/html/rfc7231#section-5.3.2:
没有任何Accept标头字段的请求意味着用户代理将接受任何媒体类型作为响应。
您应该将不存在的Accept
标题视为*/*
。
答案 2 :(得分:0)
距上次回答已经过去几年了,所以这里是当前的 RFC 7231,它与以前的 RFC 保持相同的建议:
<块引用>没有任何 Accept 头域的请求意味着用户代理 将接受任何媒体类型作为响应。