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 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这样的流行流解析器只是在第一个空格之后停止标头值。这意味着这些解析器并非与RFC 7230 100％兼容。

不建议使用OBS折叠，但是有许多老的Web服务器都可以生产它。因此，无论如何，您都必须在标头值中处理空格地狱。

保持解析器以纯流方式工作的唯一方法是在不修剪的情况下为用户提供空白。

Answer 3

不，你不应该，而且它只是完全无效。

<块引用>

tchar = "!" / "#" / "$" / "%" / "&" / " '" / "*" / "+" / "-" / "." / "^" / "{{ 1}}" / "_" / "`" / "|" / ~ / DIGIT
ALPHA = 1*token
tchar = field-name
token = header-field "field-name" : OWS field-value

OWS 不能有空格。

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

处理http标头中的空格

3 个答案: