如何解释空的HTTP Accept标头？

Question

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

Answer 1

来自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: */*相同。

Answer 2

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

  

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

您应该将不存在的Accept标题视为*/*。

Answer 3

距上次回答已经过去几年了，所以这里是当前的 RFC 7231，它与以前的 RFC 保持相同的建议：

<块引用>

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