在使用chunked-encoding时，我对使用“Connection”标头做什么感到困惑。应该不添加“Connection”标头（或设置为keep-alive，这与我们讨论的HTTP 1.1相同）或者是否有权将其设置为Connection：close 发送空块意味着传输结束，但这是否意味着连接结束？我以为我需要添加Connection：关闭我的意图是在发送空块后关闭连接，如果我不添加Connection头，它将保持打开
由于
答案 0 :(得分：3)
消息长度和连接管理是两个真正无关的事情（除了在消息长度完全未知的情况下，关闭连接是表示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。
如果客户端请求保持活动状态，则服务器决定是否遵守它。服务器可以使连接保持打开状态，也可以关闭连接。
如果客户端请求关闭，服务器必须尊重它并关闭连接。
发送空块意味着传输结束，但这是否意味着连接结束？
没有。只有Connection标题可以做到这一点。特别是在keep-alive场景中，因此连接保持打开状态，以便客户端可以重复使用现有连接，在完成上一个响应的传输后发送新请求。
我认为我需要添加Connection：关闭我的意图是在发送空块后关闭连接
正确，尤其是在HTTP 1.1+中keep-alive是默认行为。
如果我不添加Connection标头，它将保持打开状态
省略的Connection标头的含义取决于所使用的HTTP版本，如上所述。
答案 1 :(得分：0)
允许服务器在使用分块传输编码的同时发送Connection: close，这不应导致客户端在响应完成之前就断开连接。
根据RFC2616 https://tools.ietf.org/html/rfc2616#section-14.10
例如，
请求或响应标头字段中的Connection: close表示 连接不应视为“持久”（8.1节） 当前请求/响应完成后。
由于发送块时响应未完成，因此不禁止连接持久化。