如果我的 HTTP 服务器收到带有“Connection: keep-alive”标头的 HTTP/1.0 请求，那么客户端会理解“Transfer-Encoding: chunked”是否公平？
基本上，我正在尝试决定是否接受来自 HTTP/1.0 客户端的“Connection: keep-alive”标头。如果我确实尊重它，那么我必须对回复使用分块编码，因为我无法缓冲整个回复以计算 Content-Length 标头。
如果期望请求“连接：保持活动”的 HTTP/1.0 客户端也能理解分块编码是不安全的，那么我将不得不在每次回复后关闭连接。 （或者我错过了什么？）
【问题讨论】：
标签： http http-headers chunked-encoding http-content-length http-chunked
这是一个明确的“不”。引用规范：
但是，无法与 HTTP/1.0 客户端建立持久连接 使用分块传输编码，因此必须使用 Content-Length 用于标记每条消息的结束边界。
【讨论】：
在 HTTP 1.0 中不能进行分块传输编码。使用分块传输编码的保活请求实际上是 HTTP 1.0 和 1.1 之间的定义差异之一。
为了使服务器能够使用并非所有客户端都支持的某些功能，例如保持活动或分块传输编码，它必须在开始响应之前知道客户端与该功能兼容，因为存在在初始请求之后，客户端和服务器之间没有正在进行的双向通信。
Keep-alive 本身可以在 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 和分块传输编码，因此在发出 HTTP 1.1 请求时，客户端只需将 HTTP/1.1 指定为协议，而不指定 Keep-Alive 标头。
实际上，即使服务器仅支持 HTTP 1.0，客户端仍然可以发送 keep-alive 标头，因此它可以使用 keep-alive。如果服务器支持 HTTP 1.1 或更高版本，则该标头将被忽略，并且 HTTP/1.1 协议指示符优先。注意：我相信今天的服务器不支持 HTTP 1.1 或更高版本但仍支持保持活动状态的情况非常罕见，因此发送它很少有用。
【讨论】：
肯定不是，因为Transfer-Encoding 仅在 HTTP 1.1 中。鉴于您的情况，我认为您不能真正支持 HTTP 1.0 客户端的 Connection: keep-alive 标头（对于您的用例，HTTP 1.0 支持它）。您应该忽略它并关闭连接。这样做是安全的，因为它实际上只是一种优化。
【讨论】：