在使用分块编码时，我对如何处理“连接”标头有点困惑。是否应不添加“Connection”标头（或设置为 keep-alive，这与我们讨论的 HTTP 1.1 相同）或者是否有权将其设置为 Connection:close 发送一个空块，意味着传输结束，但是否意味着连接结束？我认为我需要添加 Connection:close 当我的意图是在发送空块后关闭连接时，如果我不添加 Connection 标头，它将保持打开状态
谢谢
【问题讨论】：
标签： http chunked-encoding
消息长度和连接管理是两个不同的东西，实际上彼此无关（除了在一种情况下消息长度完全未知并且关闭连接是表示 EOF 的唯一可能方式，但这很少发生，而不是你的情况）。
分块仅适用于消息长度，其中 0 长度的块表示 EOF。如果连接在到达 EOF 之前提前关闭，则消息不完整，接收方可以决定是否保留/处理它。
客户端使用Connection 标头来指定它是希望服务器在发送响应后关闭连接还是保持打开状态。服务器使用相同的标头来指定在发送响应后连接是实际关闭还是保持打开。
是否应不添加“Connection”标头（或设置为 keep-alive，这与我们讨论的 HTTP 1.1 相同）或者是否有权将其设置为 Connection:close
这与分块无关。无论消息的格式如何，客户端和服务器都应该始终表明它们对当前连接的意图，无论它应该关闭还是保持打开状态。这是通过存在或不存在 Connection 标头来完成的，具体取决于 HTTP 版本：
如果使用 HTTP 1.0，默认行为是 close，除非明确发送 Connection: keep-alive。
如果使用 HTTP 1.1+，默认行为是 keep-alive，除非显式发送 Connection: close。
如果客户端请求保持活动状态，则服务器决定是否接受它。服务器可以保持连接打开，也可以关闭连接。
如果客户端请求关闭，服务器必须遵守并关闭连接。
发送一个空的chunk，表示传输结束，但是否表示连接结束？
没有。只有 Connection 标头可以做到这一点。尤其是在keep-alive 场景中，因此连接保持打开状态，以便客户端可以在先前响应的传输完成后重用现有连接发送新请求。
当我打算在发送空块后关闭连接时，我认为我需要添加 Connection:close
正确，尤其是在 HTTP 1.1+ 中，keep-alive 是默认行为。
如果我不添加 Connection 标头，它将保持打开状态
如上所述，省略的 Connection 标头的含义取决于所使用的 HTTP 版本。
【讨论】：
允许服务器在使用分块传输编码时发送Connection: close，这不应导致客户端在响应完成之前断开连接。
根据 RFC2616 https://www.rfc-editor.org/rfc/rfc2616#section-14.10
例如，
Connection: close在请求或响应头字段中表明 连接不应该被认为是“持久的”（第 8.1 节） 当前请求/响应完成后。
由于在发送块时响应未完成，因此不禁止连接持续。
【讨论】：