如果HTTP / 1.0客户端请求Connection：keep-alive，它会理解分块编码吗？

Question

如果我的HTTP服务器获得带有“Connection：keep-alive”标头的HTTP / 1.0请求，那么客户是否理解“Transfer-Encoding：chunked”是否公平？

本质上，我正在尝试决定是否尊重HTTP / 1.0客户端的“Connection：keep-alive”标头。如果我确实尊重它，那么我必须使用分块编码进行回复，因为我无法缓冲整个回复以计算Content-Length标头。

如果期望请求“Connection：keep-alive”的HTTP / 1.0客户端也理解分块编码是不安全的，那么我将不得不在每次回复后关闭连接。 （或者我错过了什么？）

Answer 1

这是一个明确的“号”从规范中引用：

但是，与HTTP / 1.0客户端的持久连接不能使用分块传输编码，因此必须使用Content-Length来标记每个消息的结束边界。

- RFC 2068 §19.7.1

Answer 2

HTTP 1.0中不能进行分块传输编码。具有分块传输编码的保持活动请求实际上是HTTP 1.0和1.1之间的定义差异之一。

为了使服务器能够使用并非所有客户端都支持的功能，例如保持活动或分块传输编码，它必须在开始响应之前知道客户端与该功能兼容，因为没有正在进行的初始请求后客户端和服务器之间的双向通信。

• 在HTTP 1.0中可以支持Keep-alive本身，因为客户端可以在请求中包含Keep-Alive标头，向服务器指示客户端支持它。
• HTTP 1.0客户端没有确定的方式来指示它们支持分块传输编码，因此服务器无法向HTTP 1.0请求发送分块响应。如果您要向不理解它的客户端发送分块响应，客户端将收到垃圾。 当HTTP 1.0使用keep-alive时，它没有分块传输编码。
• 当keep-alive不能使用分块传输编码时，它必须为每个响应发送一个Content-Length头。这意味着只有在服务器知道响应开始时响应的内容长度以生成有效的Content-Length头时，才能在HTTP 1.0中实现keep-alive。当脚本生成响应并且服务器在发送之前没有完全缓冲它时，情况可能不是这样。 如果服务器在开始发送响应之前不知道响应的内容长度，则服务器只会禁用该响应的保持活动状态。服务器并不强制要求每个响应都是保持活动响应。
• HTTP 1.1客户端必须支持keep-alive和chunked transfer-encoding，因此在发出HTTP 1.1请求时，客户端只需指定HTTP / 1.1作为协议，并且不指定Keep-Alive头。 在实践中，客户端仍然可以发送keep-alive头，因此即使服务器仅支持HTTP 1.0，它也可以使用keep-alive。如果服务器支持HTTP 1.1或更高版本，则将忽略该标头，并且HTTP / 1.1协议指示符优先。注意：我认为今天的服务器很少支持HTTP 1.1或更高版本，但仍然支持keep-alive，所以发送它很少有用。

Answer 3

绝对不是，因为Transfer-Encoding仅在HTTP 1.1中。鉴于您的情况，我认为您不能真正支持HTTP 1.0客户端的Connection: keep-alive标头（对于您的用例，HTTP 1.0支持它）。您应该忽略它并关闭连接。你可以安全地做到这一点，因为它只是一个优化。