http - 如何解释空的 HTTP Accept header ？

Question

HTTP/1.1 Accept请求 header 在 RFC 2616, section 14.1 中指定.

它的语法是这样的:

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

#根据section 2.1，没有任何数字状态零个或多个 .但是，第 14.1 节没有说明如何解释空的 Accept。 header 。这与 section 14.2 形成对比，其中谈到 Accept-Encoding ，其中不仅1#使用(一个或多个)，但对于空的 Accept-Encoding 也是如此 header 已指定，这有点奇怪。其他一些处理请求 header 的部分也特定于空值的特殊情况。

一个人应该对待一个空的 Accept标题等同于不存在 Accept标题？我错过了这方面的任何官方资源吗？

Answer 1

来自 RFC2616 Sec4.2 :

Each header field consists of a name followed by a colon (":") and the field value.

乍一看，这似乎将指定空 header 值的邮件置于格式错误、不合规的类别中。然而，RFC2616 Sec2.1 中概述的增强 BNF 形式表示

"#element" allows any number, including zero

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

由于规范中的以下指示，解析空 header 和仅包含空格的 header 可能会出现问题:

The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS MAY be removed without changing the semantics of the field value. Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.

恕我直言，发送空 header 完全没有意义。不应该这样做，解析器可能无法正确解析这些 header 。传统上，在处理不兼容组件时想要规避此类限制的人会指定如下“伪空”值:

X-MyCustomHeader: ""

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

---

更新

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

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

这是合理的，但不是 RFC2616 Sec14.1 所要求的:

If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

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