时间戳

首页 > 解决方案 > 由 HTTP 增强的 ABNF：#symbol 的规范性参考

http - 由 HTTP 增强的 ABNF：#symbol 的规范性参考

问题描述

语境

解决一个CORS问题，我想知道 HTTP 响应标头的有效值是什么Access-Control-Allow-Headers。

Whatwg CORS 标头语法规范在 ABNF 中告诉我：

Access-Control-Allow-Headers = #field-name

RFC7230告诉我：

field-name     = token
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA

此外，Whatwg 指出：

ABNF 表示 ABNF 由 HTTP（特别是添加 #）和 RFC 7405 增强。[RFC7405]

好的，我现在知道这个响应头是无效的：

Access-Control-Allow-Headers: Origin, Content-Type, content type, Accept, Authorization

字段名不应包含空格，但这会导致我的问题：

问题

#symbolwhatwg ABNF的规范参考在哪里？这不是定义 ABNF 语法的RFC5234 。我把它当作逗号分隔的字段，但我没有找到真正的参考。

PS：问题不是“什么是有效值Access-Control-Allow-Headers”

标签： httpspecificationsabnf

解决方案

这个“由 HTTP 增强（特别是添加 #）”来自RFC 7230 - 超文本传输​​协议（HTTP/1.1）：消息语法和路由第 7 节。 ABNF 列表扩展：#rule：

[RFC5234] 的 ABNF 规则的#rule 扩展用于提高某些标头字段值定义的可读性。

定义了一个构造“#”，类似于“*”，用于定义以逗号分隔的元素列表。完整的形式是“ <n>#<m>element”，表示至少<n>和最多<m>元素，每个元素由一个逗号（“，”）和可选的空格（OWS）分隔。

在任何使用列表构造的产品中，发送者不得生成空列表元素。换句话说，发送者必须生成满足以下语法的列表：

1#元素 => 元素 *( OWS "," OWS 元素)

(...)

所以#field-name变成“零个或多个field-name（用逗号分隔并由可选的线性空格包围）”，因为 n 和 m 分别默认为 0 和无穷大。

推荐阅读