分块编码和 connection:close 在一起
chunked encoding and connection:close together
我有点困惑在使用 chunked-encoding 时如何处理 "Connection" header。 "Connection" header 是不是应该不加（或者设置为 keep-alive，这和我们说的 HTTP 1.1 是一样的）还是授权设置为 Connection:close
发送一个空块，意味着传输结束，但是否意味着连接结束？我认为我需要添加 Connection:close 当我打算在发送空块后关闭连接时，如果我不添加连接 header，它将保持打开状态
谢谢
消息长度和连接管理是两个不同的东西，实际上彼此无关（除了消息长度完全未知并且关闭连接是表示 EOF 的唯一可能方式的情况，但是这种情况很少发生，也不是你的情况）。
分块仅适用于消息长度，其中长度为 0 的块表示 EOF。如果连接在到达 EOF 之前过早关闭，则消息不完整，接收方可以决定是否 keep/process 它。
客户端使用Connection header 指定它是希望服务器在发送响应后关闭连接还是保持打开状态。服务器使用相同的 header 来指定在发送响应后连接是实际关闭还是保持打开状态。
Shall the "Connection" header not be added (or set to keep-alive, which is the same as we're talking about HTTP 1.1) or is this authorized to set it to Connection:close
这与分块无关。无论消息的格式如何，客户端和服务器都应该始终表明它们对当前连接的意图，无论是应该关闭还是保持打开状态。这是通过存在或不存在 Connection header 来完成的，具体取决于 HTTP 版本：
如果使用 HTTP 1.0，默认行为是 close，除非明确发送 Connection: keep-alive。
如果使用 HTTP 1.1+，默认行为是 keep-alive，除非明确发送 Connection: close。
如果客户端请求 keep-alive，服务器决定是否接受它。服务器可能会保持连接打开，也可能会关闭连接。
如果客户端请求关闭，服务器必须尊重它并关闭连接。
Sending an empty chunk, means the end of the transfer, but does it mean the end of the connection?
没有。只有 Connection header 会这样做。特别是在 keep-alive 场景中，因此连接保持打开状态，以便客户端可以在先前响应的传输完成后重用现有连接来发送新请求。
I thought that I would need to add Connection:close when my intention is to close the connection after an empty chunk has been sent
正确，尤其是在 HTTP 1.1+ 中，其中 keep-alive 是默认行为。
where if I don't add the Connection header, it would remain open
省略的 Connection header 的含义取决于所使用的 HTTP 版本，如上所述。
允许服务器在使用分块传输编码时发送 Connection: close，这不应导致客户端在响应完成之前断开连接。
根据 RFC2616 https://www.rfc-editor.org/rfc/rfc2616#section-14.10
For example,
Connection: close
in either the request or the response header fields indicates that
the connection SHOULD NOT be considered `persistent' (section 8.1)
after the current request/response is complete.
由于在发送块时响应未完成，因此不禁止连接持续。
我有点困惑在使用 chunked-encoding 时如何处理 "Connection" header。 "Connection" header 是不是应该不加（或者设置为 keep-alive，这和我们说的 HTTP 1.1 是一样的）还是授权设置为 Connection:close 发送一个空块，意味着传输结束，但是否意味着连接结束？我认为我需要添加 Connection:close 当我打算在发送空块后关闭连接时，如果我不添加连接 header，它将保持打开状态
谢谢
消息长度和连接管理是两个不同的东西，实际上彼此无关（除了消息长度完全未知并且关闭连接是表示 EOF 的唯一可能方式的情况，但是这种情况很少发生，也不是你的情况）。
分块仅适用于消息长度，其中长度为 0 的块表示 EOF。如果连接在到达 EOF 之前过早关闭，则消息不完整，接收方可以决定是否 keep/process 它。
客户端使用Connection header 指定它是希望服务器在发送响应后关闭连接还是保持打开状态。服务器使用相同的 header 来指定在发送响应后连接是实际关闭还是保持打开状态。
Shall the "Connection" header not be added (or set to keep-alive, which is the same as we're talking about HTTP 1.1) or is this authorized to set it to Connection:close
这与分块无关。无论消息的格式如何，客户端和服务器都应该始终表明它们对当前连接的意图，无论是应该关闭还是保持打开状态。这是通过存在或不存在 Connection header 来完成的，具体取决于 HTTP 版本：
如果使用 HTTP 1.0，默认行为是 close，除非明确发送 Connection: keep-alive。
如果使用 HTTP 1.1+，默认行为是 keep-alive，除非明确发送 Connection: close。
如果客户端请求 keep-alive，服务器决定是否接受它。服务器可能会保持连接打开，也可能会关闭连接。
如果客户端请求关闭，服务器必须尊重它并关闭连接。
Sending an empty chunk, means the end of the transfer, but does it mean the end of the connection?
没有。只有 Connection header 会这样做。特别是在 keep-alive 场景中，因此连接保持打开状态，以便客户端可以在先前响应的传输完成后重用现有连接来发送新请求。
I thought that I would need to add Connection:close when my intention is to close the connection after an empty chunk has been sent
正确，尤其是在 HTTP 1.1+ 中，其中 keep-alive 是默认行为。
where if I don't add the Connection header, it would remain open
省略的 Connection header 的含义取决于所使用的 HTTP 版本，如上所述。
允许服务器在使用分块传输编码时发送 Connection: close，这不应导致客户端在响应完成之前断开连接。
根据 RFC2616 https://www.rfc-editor.org/rfc/rfc2616#section-14.10
For example,
Connection: closein either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete.
由于在发送块时响应未完成，因此不禁止连接持续。