如果我的 HTTP 服务器收到带有“Connection: keep-alive”标头的 HTTP/1.0 请求，那么客户端会理解“Transfer-Encoding: chunked”是否公平？
本质上，我正在尝试决定是否尊重来自 HTTP/1.0 客户端的“Connection: keep-alive”标头。如果我确实尊重它，那么我必须对回复使用分块编码，因为我无法缓冲整个回复以计算 Content-Length 标头。
如果期望请求“连接：保持活动”的 HTTP/1.0 客户端也能理解分块编码是不安全的，那么我将不得不在每次回复后关闭连接。（或者我错过了什么？）
这是一个明确的“不”。引用规范：
但是，与 HTTP/1.0 客户端的持久连接不能使用分块传输编码，因此必须使用 Content-Length 来标记每个消息的结束边界。
在 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 和分块传输编码，因此在发出 HTTP 1.1 请求时，客户端只需将 HTTP/1.1 指定为协议，而不指定 Keep-Alive 标头。
实际上，客户端可能仍会发送 keep-alive 标头，因此即使服务器仅支持 HTTP 1.0，它也可以使用 keep-alive。如果服务器支持 HTTP 1.1 或更高版本，则该标头将被忽略，并且 HTTP/1.1 协议指示符优先。注意：我相信今天的服务器很少支持 HTTP 1.1 或更高版本，但仍支持保持活动，因此发送它很少有用。
绝对不是，因为它Transfer-Encoding仅在 HTTP 1.1 中。鉴于您的情况，我认为您不能真正支持Connection: keep-aliveHTTP 1.0 客户端的标头（对于您的用例，HTTP 1.0 支持它）。您应该忽略它并关闭连接。这样做是安全的，因为它实际上只是一种优化。