带有传输编码分块的 HTTP GET答案

【问题标题】：HTTP GET with Transfer-Encoding Chunked带有传输编码分块的 HTTP GET
【发布时间】：2017-06-30 15:48:17
【问题描述】：

我最近看到一个将 Transfer-Encoding 标头设置为 Chunked 的 GET 调用。我们从这个调用中注意到的是延迟，然后是 500 个套接字超时。

深入挖掘，我们展示了来自 ELB 和 Apache Web 服务器的 500 的这种行为。

值得注意的是，如果我们使用 Transfer-Encoding 作为 Chunked 进行 GET 调用并包含一个空的有效负载，则本例中的 ELB 允许请求正常通过。

鉴于这个 ELB 和 Apache 网络服务器表现出这种行为，我的问题是在 HTTP GET 调用上发送传输编码作为分块是否有效？

【问题讨论】：

【解决方案1】：

Transfer-Encoding 标头现在由RFC 7230, section 3.3.1 授权（另请参阅IANA Message Header Registry。您会发现此标头是 HTTP 消息框架的一部分，因此它对请求和响应均有效。

请记住GET requests may carry bodies，服务器的反应是绝对正确的。导致 500 后出现延迟的原因可能如下：服务器会期望一个主体，但找不到主体，因为空字符串的块编码表示不是空字符串，而是zero-sized chunk。结果，服务器运行超时。

【讨论】：

请记住，规范禁止将任何语义分配给 GET 请求正文的含义。因此，许多代理（例如代理）可能会剥离或阻止带有正文的 GET 请求，因此建议避免这种情况。
@Adrien 虽然是真的，但这有点超出了这个问题的范围。我想表明GET 请求允许有一个主体根本，因此Transfer-Encoding 标头不会放错在这里。
明白了，和Content-Length一样，Transfer-Encoding:chunked请求头的存在说明有body，因此需要补全。
@Adrien 实际上我刚才必须检查一下。似乎您是not entirely correct：在某些情况下，值> 0 的Content-Length 标头可以与空主体一起有效。我必须承认，我不知道这一点；我只是假设除了Content-Length: 0 之外的任何东西在这里都是无效的。
请求消息更加清晰和限制。由于您必须保持连接（因此是框架）才能接收响应。如果您的 Content-Length > 0 并且不发送正文，则会破坏框架。您不能在请求中发送无效（错误值）C-L 并期望一切正常。如果你也发送 T-E:chunked，你可以发送错误的 C-L，因为 C-L 应该被忽略，但我也不会依赖这个。