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

问题描述

HTTP/1.1 Accept 请求标头在 RFC 2616，第 14.1 节.

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

它的语法是这样的:

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

# 根据 第 2.1 节.但是，第 14.1 节没有说明如何解释空的 Accept 标头.这与讨论 Accept-Encoding，其中不仅使用了1#(一个或多个)，还使用了空的Accept-Encoding 标头，这有点奇怪.处理请求标头的其他一些部分也专门针对空值的特殊情况.

# 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.

是否应该将 empty Accept 标头等同于 不存在 Accept 标头?有没有我错过的官方资源?

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

推荐答案

来自 RFC2616 Sec4.2:

每个标题字段由一个名称后跟一个冒号(:")和字段值组成.

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

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

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" 允许任何数字，包括零

"#element" allows any number, including zero

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

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:

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

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.

更新

我想我在直接回答问题时不是很清楚:对于空的 Accept 标头，您确实有两个选择:

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:

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

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

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

This is justified, but not required by RFC2616 Sec14.1:

如果存在 Accept 标头字段，并且服务器无法发送根据组合接受字段可接受的响应值，那么服务器应该发送一个 406(不可接受的)响应.

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.

• 或者，因为这不是必需的，并且用户不太可能不接受 any 内容类型(否则，他们为什么还要费心发送请求?)...我建议将空的 Accept: 值(如果不能选择消息拒绝)与 Accept: */* 相同.
• 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屋！