Connection头字段（6.1节）提供了一个“close”连接选项，当发送者希望在当前的请求/响应对之后关闭连接就会发送它。

    发送了“close”连接选项的客户端不得进一步在那个连接（在包含“close”的消息之后）上发送请求，并且必须在读取这个请求对应的最终响应消息之后关闭连接。

    接收了“close”连接选项的服务器在它发送完包含“close”的请求的最终响应之后必须发起一个连接的关闭。服务器应该在那个连接的最终响应中发送一个“close”连接选项。服务器不得处理在那个连接上的任何后续接受到的请求。

    发送了“close”连接选项的服务器在发送包含“close”的响应之后必须发起一个连接的关闭（看下面的内容）。服务器不得处理在那个连接上的任何后续接受到的请求。（译注：这和上面那段最后一句不是一毛一样吗？？？）

    接收了“close”连接选项的客户端必须停止在那个连接上发送请求并且在读取包含“close”的响应消息之后关闭连接；如果额外的管道化请求已经在那个连接上被发送，客户端不应该假定他们会被服务器处理。

    如果一个服务器立刻关闭了连接，那么有一个巨大的风险，客户端将有可能读取不到最后的HTTP响应。如果服务器从一个完全关闭的连接上的客户端接收到额外的数据，例如另一个被客户端在接收到服务器的响应前发送的请求，服务器的TCP栈将发送一个重置包到客户端；不幸的是，重置包可能在客户端的未确认的输入缓冲能够被客户端的HTTP解析器读取和解析之前被抹去。

    为了避免TCP重置问题，服务器典型的分阶段关闭一个连接。首先，服务器通过关闭读写连接的仅写一侧来执行一个半关闭。然后，服务器继续从连接中读取数据，直到客户端收到相应的关闭，或者直到服务器合理确定自己的TCP堆栈已经收到客户端对包含服务器最后一个响应的数据包的确认。最后服务器完全关闭连接。

    重置问题是TCP独有的还是可能在其他传输连接协议中也存在是未知的。