28

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

它的语法是这样的：

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

#根据第 2.1 节，没有任何数字状态为零或多个。但是，第 14.1 节没有说明如何解释空标题。这与第 14.2 节形成对比，该节讨论，其中不仅使用（一个或多个），而且还指定了空标题的情况，这有点奇怪。处理请求标头的其他一些部分也专门针对空值的特殊情况。AcceptAccept-Encoding1#Accept-Encoding

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

4

3 回答 3

33

从RFC2616 Sec4.2：

每个标头字段由一个名称后跟一个冒号（“：”）和字段值组成。

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

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

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

由于规范中的以下方向，解析空标题和只有空格的标题可能会出现问题：

字段内容不包括任何前导或尾随 LWS：在字段值的第一个非空白字符之前或字段值的最后一个非空白字符之后出现的线性空白。可以在不更改字段值语义的情况下删除此类前导或尾随 LWS。在解释字段值或向下游转发消息之前，在字段内容之间发生的任何 LWS 都可以用单个 SP 替换。

恕我直言，发送一个空头是完全没有意义的。不应该这样做，并且解析器可能无法正确解析这些标头。传统上，在处理不合规组件时想要规避此类限制的人会指定“伪空”值，如下所示：

X-MyCustomHeader: ""

如果您只是想验证标头字段是否作为某种形式的布尔开关发送，请考虑发送像上面这样的占位符值而不是空值。

更新

我想我在直接回答这个问题时不是很清楚：在空的 Accept 标头的情况下，您确实有两个选择：

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

这是合理的，但RFC2616 Sec14.1 不需要：

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

  • 或者，因为这不是必需的，并且用户不太可能不接受任何内容类型（否则，他们为什么还要费心发送请求？）......我建议处理一个空Accept:值（如果消息拒绝不是' t 选项）与 相同Accept: */*。
于 2012-08-26T16:49:38.987 回答
6

根据https://www.rfc-editor.org/rfc/rfc7231#section-5.3.2：

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

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

于 2016-01-04T13:14:38.773 回答
0

自上一个答案以来已经有几年了，所以这里是当前的RFC 7231，它与以前的 RFC 保持相同的建议：

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

于 2021-08-03T08:14:47.033 回答