如何解释空的HTTP Accept标头？ [英] How to interpret empty HTTP Accept header?

问题描述

HTTP / 1.1 接受请求标头在 RFC 2616，第14.1节。

它的语法如下：

 接受=接受：
＃（媒体范围[accept-params]）
  

＃根据零或更多 ：//tools.ietf.org/html/rfc2616#section-2.1rel =nofollow noreferrer>第2.1节。但是，第14.1节没有说明如何解释空的 Accept 标头。这与第14.2节相反，后者讨论 Accept-Encoding ，其中不仅使用 1＃（一个或多个），而且还包括指定了一个空的 Accept-Encoding 标头，这有点奇怪。其他一些处理请求标题的部分也特定于空值的特殊情况。

应该处理空 接受标头等效于不存在 接受标头？我错过了哪些官方资源？

解决方案

来自 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标题为fie ld存在，如果服务器无法根据组合的Accept字段
值发送可接受的
响应，则服务器应该发送406（不可接受）响应。

• 或者，因为这不是必需的，并且用户不太可能不接受任何内容-types（否则，为什么他们懒得发送请求？）...我建议处理一个空的接受：值（如果消息拒绝不是一个选项）与相同接受：* / * 。

The HTTP/1.1 Accept request header is specified in RFC 2616, section 14.1.

It's syntax is given like this:

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

# without any number states zero or more according to section 2.1. However, section 14.1 doesn't make any statement about how to interpret an empty Accept header. This is in contrast to section 14.2, which talks about Accept-Encoding, where not only 1# is used (one or more), but also the case for an empty Accept-Encoding header is specified, which is kind of weird. Some other sections dealing with request headers are also specific on the special case of an empty value.

Should one treat an empty Accept header equivalently to a non-existent Accept header? Are there any official resources on this I missed?

解决方案

From RFC2616 Sec4.2:

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

At first glance, this would seem to put messages that specify empty header values in the malformed, non-compliant category. However, the augmented BNF form outlined in RFC2616 Sec2.1 indicates that

"#element" allows any number, including zero

As this is the declaration used to specify Accept header values, it appears that empty values are valid.

Parsing empty headers and headers with nothing but whitespace can be problematic because of the following direction from the spec:

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.

IMHO, sending an empty header is completely pointless. It shouldn't be done, and parsers may not correctly parse these headers. Traditionally, people who want to circumvent such limitations when dealing with non-compliant components have specified "pseudo-empty" values like this:

X-MyCustomHeader: ""

If you simply want to validate that a header field was sent as some form of boolean switch, consider sending a placeholder value like the above instead of an empty value.

---

Update

I guess I wasn't very clear in directly answering the question: in the case of an empty Accept header you really have two options:

• Send a 406 Not Acceptable response to inform the client that you don't offer any content types for an empty Accept value (duh).

This is justified, but not required by 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.

• Or, because this is not required and it's highly unlikely the user doesn't accept any content-types (otherwise, why would they bother to send the request?) ... I would suggest treating an empty Accept: value (if message rejection isn't an option) the same as Accept: */*.

这篇关于如何解释空的HTTP Accept标头？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！