☰

HTTP“连接”标头中的连接令牌的有效性

tag-icon • tag-icon http headers
HTTP“连接”标头中的连接令牌的有效性

对于在 HTTP“连接”标头中可以发送什么作为连接令牌，是否有任何规则？例如，非字母数字字符（除了-）是否{被/允许？

另外，标头中是否有有效连接令牌列表，还是开放式的？例如，、、、甚至是否被Keep-Alive视为有效- 只要接收端知道如何处理它们，就可以允许？还是所有接收端都只允许并丢弃/忽略其余部分？Keep-alivekeep-alivekeepalivekeel-aliveKeep-Alive

答案1

对于在 HTTP“连接”标头中可以发送什么作为连接令牌，是否有任何规则？例如，是否允许使用非字母数字字符（除了 - 之外），如 { 或 /？

是的，当然有规则。HTTP/1.1 中此标头的语法定义在RFC 2616 第 14.10 节， 之后RFC 7230 第 6.1 节：

   The Connection header field's value has the following grammar:

     Connection        = 1#connection-option
     connection-option = token

   Connection options are case-insensitive.

1#意思是逗号分隔的元素列表语法token定义在RFC 2616 第 2.2 节，后来修订于RFC 7230 第 3.2.6 节：

   token          = 1*<any CHAR except CTLs or separators>
   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

   CHAR           = <any US-ASCII character (octets 0 - 127)>
   CTL            = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
   SP             = <US-ASCII SP, space (32)>
   HT             = <US-ASCII HT, horizontal-tab (9)>

这意味着/和{明确不允许作为“分隔符”，但许多其他非字母数字仍然被允许；例如，.或&或被$隐式允许，因为它们包含在 CHAR 中并且未列为分隔符。

RFC 7230 中修订的规则引用了RFC 5234 附录 B.1对于 VCHAR，并明确允许的非字母数字字符列表（尽管它实际上仍然与之前完全相同的列表）。

   token          = 1*tchar
   tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                  / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                  / DIGIT / ALPHA
                  ; any VCHAR, except delimiters

(From RFC 5234)

   VCHAR          = %x21-7E
                  ; visible (printing) characters

另外，标题中是否有有效连接令牌的列表，或者它是开放式的？

分子动力学说：“任何以逗号分隔的 HTTP 标头列表”。

根据 HTTP/1.1 RFC，基本的此标头的目的是开放的，因为它应该列出其他逐跳请求标头的名称。HTTP/1.1 规范还定义了一些与标头名称无关的标记，例如close，但任何未被识别为特定选项的内容都将被视为逐跳标头的名称。

例如，Keep-Alive、Keep-alive、keep-alive、keepalive 和 even keel-alive 是否被视为有效 - 只要接收端知道如何处理它们，就可以允许？还是所有接收端都只允许 Keep-Alive 并丢弃/忽略其余的？

规范中规定为Connection options are case-insensitive，这是意料之中的，因为连接选项主要引用 HTTP 标头名称，而 HTTP 标头名称本身不区分大小写。这意味着令牌Keep-alive和keep-alive将被识别为具有相同含义，而keepalive和keel-alive仍然是一般有效的令牌，但引用不同的 HTTP 标头。

然而，没有任何这些令牌需要接收端“知道如何处理它们”，因为 HTTP/1.1 中的连接默认已经是持久的——只有相反的行为才需要带有“关闭”令牌的连接标头。

因此，Keep-AliveHTTP/1.1 中没有对令牌进行特殊定义；它不是一个独立的令牌（如“close”），而只是引用 Keep-Alive 标头（如果存在）。（HTTP/1.1 的旧版本，RFC 2068 第 19.7.1 节，定义 Keep-Alive 标头以与非标准 HTTP/1.0 扩展兼容。）

相关内容