处理 http 标头中的空格答案

【问题标题】：Handling whitespaces in http headers处理 http 标头中的空格
【发布时间】：2019-12-27 05:41:40
【问题描述】：

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

例如，一个符合 HTTP/1.1 的客户端是否应该解释这个：

Connection  :   close      \r\n

这样：

Connection: close\r\n

【问题讨论】：

标签： http

【解决方案1】：

不，你不应该这样做，而且这完全是无效的。

tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+ " / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / @987654338 @

token = 1*tchar

field-name = token

header-field = field-name ":" OWS field-value OWS

field-name 不能有空格。

在Connection : close \r\n中，field-name为Connection ，无效。

【讨论】：

【解决方案2】：

见RFC 7230 Appendix B. Collected 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 还是OWS 的一部分。因此，您必须在接收非空白字节或\r\n 之前存储空白。 b + 空格 + c 和 d + 空格也是一样的。

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

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

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

【讨论】：

【解决方案3】：

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

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

【讨论】：

您引用了一个 18 年前的规范，该规范已经过时了两次。
你是对的。我更新了我的答案以引用当前的 HTTP/1.1 规范 (RFC2616)，内容几乎不一样。
RFC 2616 是一个已有 16 年历史的规范，从那以后已经过时了一次。
当前的 RFC 是 greenbytes.de/tech/webdav/rfc7230.html>，与此相关的大部分文本已经从头开始重写。请参阅 greenbytes.de/tech/webdav/rfc7230.html#header.fields>。
好的。在那里我可以读到：“每个标题字段由一个不区分大小写的字段名称后跟一个冒号（“：”）、可选的前导空格、字段值和可选的尾随空格组成。”。那就没什么新意了。谢谢。