HTTP 标头值中允许使用哪些字符？

Question

在研究了HTTP/1.1 standard，特别是第 31 页和相关之后，我得出结论，任何 8 位八位字节都可以出现在 HTTP 标头值中。 IE。代码在 [0,255] 范围内的任何字符。

然而，我尝试过的 HTTP 服务器拒绝接收任何代码 > 127（或大多数 US-ASCII 不可打印字符）的内容。

这是标准中使用的语法摘录：

message-header = field-name ":" [ field-value ]
field-name     = token
field-value    = *( field-content | LWS )
field-content  = <the OCTETs making up the field-value and consisting of
                  either *TEXT or combinations of token, separators, and
                  quoted-string>

CR             = <US-ASCII CR, carriage return (13)>
LF             = <US-ASCII LF, linefeed (10)>
SP             = <US-ASCII SP, space (32)>
HT             = <US-ASCII HT, horizontal-tab (9)>
CRLF           = CR LF
LWS            = [CRLF] 1*( SP | HT )
OCTET          = <any 8-bit sequence of data>
CHAR           = <any US-ASCII character (octets 0 - 127)>
CTL            = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
TEXT           = <any OCTET except CTLs, but including LWS>

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

quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext         = <any TEXT except <">>
quoted-pair    = "\" CHAR

如您所见，field-content 可以是quoted-string，它是TEXT 的引用序列（即除" 和[0-8, 11-12, 14-31, 127] 范围内的值之外的任何8 位八位字节）或@987654332 @（\ 后跟 [0, 127] 范围内的任何值）。 IE。任何 8 位 char 序列都可以通过对其进行 en-quoting 并在特殊符号前加上 \ 来传递。

（请注意，标准不会以任何特殊方式对待NUL(0x00) char）

但是，很明显，要么我尝试的所有服务器都不符合标准，要么标准自 1999 年以来发生了变化，或者我无法正确阅读。

那么... HTTP 标头值中允许使用哪些字符以及为什么？

附：这一切背后的原因：我正在寻找一种在 HTTP 标头值中传递 utf-8 编码序列的方法（如果可能，无需额外编码）。

Answer 1

RFC 2616已过时，相关部分已替换为RFC 7230。

NUL 字节不再允许在注释和引用字符串文本中， 并澄清了其中的反斜杠转义处理。这 引用对规则不再允许转义其他控制字符 比 HTAB。 标头字段中的非 US-ASCII 内容和原因短语 已被废弃并变得不透明（TEXT 规则已被删除）。 （第 3.2.6 节）

本质上，RFC 2616 默认为ISO-8859-1，这既不够用又不能互操作。因此，RFC 7230 已弃用字段值中的非 ASCII 八位字节。建议在此基础上使用转义机制（例如在RFC 8187 中定义，或纯 URI-percent-encoding）。

Answer 2

看起来HTTP/1.1 specs 中有错误。正如您所指出的，第 4.2 节将字段内容描述为 OCTET：

field-content = 组成字段值的 OCTET

并且 OCTET 在 §2.2 中定义为：

OCTET = 任何 8 位数据序列

这些行是您得出应该允许八位字节 > 127 的结论的基础，当然我知道您是如何得出这个结论的。 §4.2 中提到的 OCTET 是误导性错误；它应该是 CHAR。

如果您从头开始阅读第 4.2 节（消息头），您会注意到以下指导：

HTTP 标头字段...遵循与 RFC 822 的第 3.1 节中给出的相同的通用格式

如果我们按照指示进行操作并转到RFC 822，特别是第 3.1.2 节（标头字段的结构），我们会了解到以下内容：

字段名必须由可打印的 ASCII 字符组成 （即，值介于 33. 和 126. 之间的字符， 小数，冒号除外）。 字段体可以由任何 ASCII 字符，CR 或 LF 除外。

因此，虽然 HTTP/1.1 是在 1999 年编写的，但他们使用 1982 年的定义来描述字段内容。 1982 年，字符 0-127 被称为“ASCII”，而 128-255 被称为“扩展 ASCII”。现在，在这个答案中，我不会涉及the food fight，这是在使用术语“扩展 ASCII”时引起的。 我将简单地向您指出 RFC 822 的 §3.3 以了解当时被视为“任何 ASCII 字符”的定义：

CHAR = 任何 ASCII 字符（八进制：0-177，十进制：0.-127。）

所以你有它 - 确凿的证据。 “ASCII”在 1982 年停在 127 处。RFC 2616 §4.2 的书面段落部分为您指明了正确的方向，不幸的是后来在同一部分中误用了令牌 OCTET 导致您陷入了这个兔子洞。