Network Working Group R. Fielding Request for Comments: 2616 ...

- Latency on subsequent requests is reduced since there is no timespent in TCP's connection opening handshake.- HTTP can evolve more gracefully, since errors can be reportedwithout the penalty of closing the TCP connection. Clients usingfuture versions of HTTP might optimistically try a new feature,but if communicating with an older server, retry with oldsemantics after an error is reported.HTTP implementations SHOULD implement persistent connections.Fielding, et al. Standards Track [Page 44]RFC 2616 HTTP/1.1 June 19998.1.2 Overall OperationA significant difference between HTTP/1.1 and earlier versions ofHTTP is that persistent connections are the default behavior of anyHTTP connection. That is, unless otherwise indicated, the clientSHOULD assume that the server will maintain a persistent connection,even after error responses from the server.Persistent connections provide a mechanism by which a client and aserver can signal the close of a TCP connection. This signaling takesplace using the Connection header field (section 14.10). Once a closehas been signaled, the client MUST NOT send any more requests on thatconnection.8.1.2.1 NegotiationAn HTTP/1.1 server MAY assume that a HTTP/1.1 client intends tomaintain a persistent connection unless a Connection header includingthe connection-token "close" was sent in the request. If the serverchooses to close the connection immediately after sending theresponse, it SHOULD send a Connection header including theconnection-token close.An HTTP/1.1 client MAY expect a connection to remain open, but woulddecide to keep it open based on whether the response from a servercontains a Connection header with the connection-token close. In casethe client does not want to maintain a connection for more than thatrequest, it SHOULD send a Connection header including the