如果我的HTTP服务器获得带有“Connection：keep-alive”标头的HTTP / 1.0请求，那么客户是否理解“Transfer-Encoding：chunked”是公平的赌注？
基本上，我正在尝试决定是否遵守HTTP / 1.0客户端的“Connection：keep-alive”标头。如果我确实尊重它，那么我必须使用分块编码进行回复，因为我无法缓冲整个回复以计算Content-Length标头。
如果期望请求“Connection：keep-alive”的HTTP / 1.0客户端也理解分块编码是不安全的，那么我将不得不在每次回复后关闭连接。 （或者我错过了什么？）
答案 0 :(得分：6)
这是一个明确的“号”引自规范：
但是，与HTTP / 1.0客户端的持久连接无法建立 使用分块传输编码，因此必须使用a Content-Length，用于标记每条消息的结束边界。
答案 1 :(得分：5)
HTTP 1.0中无法进行分块传输编码。使用分块传输编码的保持活动请求实际上是HTTP 1.0和1.1之间的定义差异之一。
为了使服务器能够使用并非所有客户端都支持的某些功能，例如keep-alive或chunked transfer encoding，它必须在开始响应之前知道客户端与该功能兼容，因为那里在初始请求之后，客户端和服务器之间没有正在进行的双向通信。
保持活动本身可以在HTTP 1.0中受支持，因为客户端可以在请求中包含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，所以发送它很少有用。
答案 2 :(得分：4)
绝对不是，因为Transfer-Encoding仅在HTTP 1.1中。鉴于您的情况，我认为您不能真正支持HTTP 1.0客户端的Connection: keep-alive标头（对于您的用例，HTTP 1.0支持它）。您应该忽略它并关闭连接。你这样做是安全的，因为它只是一种优化。