如何解释空的HTTP Accept标头?

时间:2012-08-26 14:27:42

标签: http http-headers string

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标头?我错过了这方面的官方资源吗?

3 个答案:

答案 0 :(得分:22)

来自RFC2616 Sec4.2

  

每个标题字段由名称后跟冒号(“:”)和字段值组成。

乍一看,这似乎会将指定空标题值的消息放入格式错误,不合规的类别中。但是,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 头域的请求意味着用户代理 将接受任何媒体类型作为响应。