主页 / computer / 问题 / 1721768
Accepted
Rayne
Asked: 2022-05-19 20:59:26 +0800 CST

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

  • 772

关于可以在 HTTP“连接”标头中作为连接令牌发送的内容是否有任何规则？例如，非字母数字字符（除了-）是否喜欢{或/允许？

此外，标头中是否有有效连接令牌列表，还是开放式的？例如，是否Keep-Alive, Keep-alive, keep-alive, keepalive, 甚至keel-alive被认为是有效的——从某种意义上说，只要接收端知道如何处理它们，它就被允许？还是所有接收端都只允许Keep-Alive和丢弃/忽略其余部分？

http headers

1 个回答

  1. Best Answer

    关于可以在 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#表示以逗号分隔的元素列表，其语法在RFC 2616 第 2.2 节token中定义，后来在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)>

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

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

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

(From RFC 5234)

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

    此外，标头中是否有有效连接令牌列表，还是开放式的？

    MDN说：“任何以逗号分隔的 HTTP 标头列表”。

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

    例如，keep-alive、keep-alive、keep-alive、keel-alive 甚至 keel-alive 是否被认为是有效的——从某种意义上说，只要接收端知道如何处理它们，就允许？还是所有接收端都只允许 Keep-Alive 并丢弃/忽略其余的？

    规范说Connection options are case-insensitive，这是预期的，因为连接选项主要引用 HTTP 标头名称，它们本身不区分大小写。这意味着标记Keep-alive和keep-alive将被识别为具有相同的含义，而keepalive通常keel-alive仍然是有效的标记，但引用不同的 HTTP 标头。

    但是，这些令牌都不需要接收端“知道如何处理它们”，因为默认情况下 HTTP/1.1 中的连接已经是持久的——只有相反的行为需要带有“关闭”令牌的 Connection 标头。

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

    • 1

相关问题