如何解释空的HTTP接受头？

HTTP/1.1

Accept

请求头在中指定

其语法如下所示：

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

#

如果没有任何数字，则根据不同的状态为零或更多。但是，第14.1节没有说明如何解释空的

Accept

标题。这与前面提到的

Accept-Encoding

相反，这里不仅使用了

1#

（一个或多个），而且还指定了空的

Accept-Encoding

头，这有点奇怪。处理请求头的其他部分也针对空值的特殊情况

是否应该将空的

接受
头等同于不存在的接受
头？有没有我错过的官方资源？
来自：

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

乍一看，这似乎将指定空头值的消息放入了格式错误的、不兼容的类别中。然而，中概述的扩充BNF表格表明

“#元素”允许任何数字，包括零

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

解析空标题和只有空格的标题可能会有问题，因为规范中有以下指示：

字段内容不包括任何前导或尾随LWS:linear
在字符的第一个非空白字符之前出现的空白
字段值，或在
字段值。此类前导或尾随LW可在无需安装的情况下拆除
更改字段值的语义。之间发生的任何LWS
字段内容可在解释前替换为单个SP
字段值或将消息转发到下游

嗯，发送一个空的头是完全没有意义的。不应该这样做，解析器可能无法正确解析这些头。传统上，在处理不符合要求的组件时，希望绕过这些限制的人会指定如下“伪空”值：

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

X-MyCustomHeader:“

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

更新

我想我没有很清楚地直接回答这个问题：在一个空的Accept头的情况下，你真的有两个选择：


发送
406 Not Acceptable
响应，通知客户端您没有为空接受值（duh）提供任何内容类型

这是合理的，但不需要：

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


或者，因为这不是必需的，而且用户很可能不接受任何内容类型（否则，他们为什么要麻烦发送请求？）。。。我建议将空的
Accept:
值（如果消息拒绝不是选项）与
Accept://*
处理相同
根据：

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

您应该将不存在的
Accept
头视为
*/*
我不同意空头格式错误，尤其是规范本身引用的是空头（请参阅我的Accept编码示例）。为了提供上下文，我正在开发PythonWeb中间件，并考虑可能发生的情况以及如何针对这些情况进行测试。我选择了假设
*/*
，这对我来说也是合理的。谢谢你抽出时间！我还认为
400错误请求
比
406不可接受
更合适，至少如果我们认为这违反了规范。因为在这种情况下，我们无法确定客户实际接受了什么。你知道，关于2616-2.1，您是对的，
#元素
表单确实表明空标题值是可以的。我将更新我的答案以反映这一点并避免错误信息。此外，我认为这使得406响应或将其视为
Accept://*
有效。但可能不是400，因为从技术上讲，这不是一条无效的消息。无论您选择的是
406
路线还是
*/*
路线，我认为在这种情况下，归结起来就是您在正确性和健壮性之间的偏好。就规范而言，这两种方法似乎都是有效的。很抱歉出现垃圾邮件。您知道有意思的是，在所有协商类型的accept头中，
accept
是唯一一个用
#element
指定的头。所有其他元素都专门定义
1#元素
。我想知道为什么？这对我来说没有多大意义，因为其他接受头遵循相同的格式（涉及q值和分隔符）。这很有趣，但从表面上看，规范设计中出现这种不一致似乎是一种失败。也许我错了，但我不明白它允许0-->n
Accept
头定义有什么用途。是的，但您引用的是一个过时的规范。当前的规范是这一个吗：？否。RFC 2616已被RFC 7230等淘汰。问题在于这里请求确实有一个Accept头字段，它只是有一个空白值。昆汀是对的，但我来这里是为了寻找cd1的确切答案。我开始欣赏相关的答案，即使它们不是直接适用的。