处理 http 标头中的空格

Question

在 http 请求/响应中是否应该忽略前导或尾随空格？

例如，如果一个符合 HTTP/1.1 的客户端解释这个：

Connection  :   close      \r\n

像这样：

Connection: close\r\n

Answer 1

根据RFC2616 (HTTP/1.1) 的第 4.2 段，字段值前面可能有空格，而不是字段名称：

每个头字段由一个名称后跟一个冒号（“:”）和字段值组成。字段名称不区分大小写。字段值前面可以有任意数量的 LWS（线性空白），但首选单个 SP。通过在每个额外的行之前至少添加一个 SP 或 HT，可以将标题字段扩展到多行。在生成 HTTP 构造时，应用程序应该遵循“通用形式”，即已知或指示的形式，因为可能存在一些无法接受任何内容的实现。

Answer 2

请参阅RFC 7230 附录 B。收集的 ABNF

header-field  = field-name ":" OWS field-value OWS
field-value   = *( field-content / obs-fold )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar   = VCHAR / obs-text

OWS表示可选空白，field-value也包括空白。您必须以某种方式忽略前导和尾随空格。

前导空格不是问题，但尾随空格会破坏流式设计。您无法以纯流方式解析 HTTP 1.1 标头（不存储任何内容）。

例如：Connection: a b \r\n b c\r\n d \r\n

您已收到a, 而非空白。field-value您无法删除此空格，因为您不知道它是否是or的一部分OWS。因此，您必须在接收非空白字节或 之前存储空白\r\n。b+ 空白 +c和d+ 空白也是同样的情况。

像 nginx/nodejs 这样的流行流解析器只是在第一个空格之后停止标头值。这意味着这些解析器并非 100% 与 RFC 7230 兼容。

OBS 折叠已被弃用，但有许多旧的网络服务器能够生成它。所以无论如何你都必须处理标头值中的空白地狱。

让解析器以纯流方式工作的唯一一种方法是向用户提供空白而不进行修剪。