传输编码分块的 HTTP 响应中的最大块大小是多少？答案

【问题标题】：What is the maximum chunk size in HTTP response with Transfer-Encoding chunked?传输编码分块的 HTTP 响应中的最大块大小是多少？
【发布时间】：2011-08-14 18:32:38
【问题描述】：

w3.org (RFC2616) 似乎没有定义块的最大大小。但是没有最大块大小，就没有块扩展的空间。必须有一个最大块大小，否则我不能忽略块扩展，因为如果无法理解，我建议这样做（引用："MUST ignore chunk-extension extensions they do not understand"）。

【问题讨论】：

为什么你认为你需要一个最大尺寸？您正在实施服务器吗？一个客户？代理？

标签： http http-headers transfer-encoding rfc2616

【解决方案1】：

每个块扩展必须以分号开头，并且块扩展列表必须以 CRLF 结尾。解析块大小时，在分号或 CRLF 处停止。如果您停在分号处，请忽略下一个 CRLF 之前的所有内容。不需要最大块大小。

chunk          = chunk-size [ chunk-extension ] CRLF
                 chunk-data CRLF

chunk-size     = 1*HEX

chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )

【讨论】：

就我在 Roland 的回答中发布的同一个问题征求您的想法。

【解决方案2】：

HTTP 规范对 HTTP 消息的语法非常清楚。

块大小总是以十六进制数的形式给出。如果该数字不是直接跟在 CRLF 后面，而是 ;，那么您就知道有一个扩展名。此扩展名由其名称 (chunk-ext-name) 标识。如果您从未听说过该特定名称，您必须忽略它。

那么你的问题到底是什么？

读取一个十六进制数
忽略直到下一个 CRLF 的所有内容
要快乐

【讨论】：

我想问一下当服务器损坏并发送永无止境的十六进制数字时你会建议做什么？成为受害者并永远读取永无止境的十六进制数字，或者修复适合您的应用程序的限制并在发生这种情况时发出警告？
@smRaj 在你的应用程序中最有意义的，可能设置一个合理的限制。
@DavidSchwartz：这有帮助。
你不能忽视，这是潜在的安全漏洞。您必须以合理的长度限制块元数据（大小和扩展列表）。
PS 这就是为什么你不应该使用废弃的 nodejs http 解析器。请看here。它不会进行溢出检查，因此可以通过简单的攻击永远挂起这个解析器。