如何解释空的HTTP Accept头？

HTTP/1.1 Accept请求标头在RFC 2616, section 14.1中指定。如何解释空的HTTP Accept头？

它的语法给出这样的：

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

#没有任何数量根据section 2.1指出零个或多个。但是，第14.1节没有说明如何解释空的Accept标题。这与section 14.2相反，其中谈到了Accept-Encoding，其中不仅使用1#（一个或多个），而且还指定了空头Accept-Encoding的情况，这有点奇怪。处理请求标头的其他部分也特定于空值的特殊情况。

如果一个同等对待的空Accept头一个不存在Accept头？有没有这方面的官方资源我错过了？

来源

2012-08-26 Jonas Wielicki

从RFC2616 Sec4.2：

每个头字段包含一个名称后面跟着冒号（“：”）和字段值。

乍一看，这似乎将消息指定为格式不正确的不符合规范的类别中的空标题值。然而，在概述的增强的BNF形式表示

“#element”允许任何数目，包括零

由于这是用于指定Accept首部值的声明，看来空值是有效的。

解析空报头和报头只包含空格可能是因为从该规范以下方向的有问题的：

的场含量不包括任何前导或尾随LWS：前线性白色空间中发生字段值的第一个非空白字符或字段值的最后一个非空白字符之后。可以在不改变字段值的语义的情况下移除这种前导或尾随的LWS。在解释字段值或向下游转发消息之前，在字段内容之间发生的任何LWS可能被替换为单个SP。

恕我直言，发送一个空头是完全没有意义的。不应该这样做，解析器可能无法正确解析这些头文件。传统上，谁想要避免与不符合要求的部件打交道时，这种限制人指定的“伪空”的价值观是这样的：

X-MyCustomHeader: ""

如果你只是想验证一个报头字段被一些发布尔开关的形式，可以考虑发送一个像上面那样的占位符值，而不是一个空值。

更新

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

发送406 Not Acceptable响应通知客户您不提供任何空白Accept值（duh）的内容类型。

这是合理的，但不能被RFC2616 Sec14.1必需的：

如果Accept首部字段的存在，并且如果服务器不能发送响应根据该结合接受字段值这是可以接受，那么服务器应该发送一个406（不可接受的）响应。

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

来源

2012-08-26 16:49:38 rdlowrey

我不同意空标题格式不正确，特别是规范本身引用了空标题（请参阅我的Accept-Encoding示例）。为了给出上下文，我正在开发python web中间件并考虑可能性以及如何对它们进行测试。我假设了''*/*''，这对我来说也是合理的。感谢您抽出宝贵的时间！ –

我也认为''400错误请求'比'406不可接受'更合适，至少如果我们认为这违反了规范。在这种情况下，我们无法弄清客户实际接受的内容。 –

你知道，你对2616-2.1是对的 - '＃element'表单确实表明空的标题值没问题。我将更新我的答案以反映这一点并避免错误信息。另外，我认为这或者是一个406响应 - 或者将它视为“Accept：*/*'有效。但可能不是400，因为它在技术上不是无效的信息。 – rdlowrey

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

的请求而无需任何Accept报头字段意味着用户代理将接受响应中的任何介质类型。

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

来源

2016-01-04 13:14:38 cd1

是的，但你引用了一个过时的规范。目前的规格是 –

：https：//tools.ietf.org/html/rfc2616#section-14.1？ – cd1

编号RFC 2616已被RFC 7230等废弃 –

如何解释空的HTTP Accept头？

回答

相关问题