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

connection-token close.If either the client or the server sends the close token in theConnection header, that request becomes the last one for theconnection.Clients and servers SHOULD NOT assume that a persistent connection ismaintained for HTTP versions less than 1.1 unless it is explicitlysignaled. See section 19.6.2 for more information on backwardcompatibility with HTTP/1.0 clients.In order to remain persistent, all messages on the connection MUSThave a self-defined message length (i.e., one not defined by closureof the connection), as described in section 4.4.Fielding, et al. Standards Track [Page 45]RFC 2616 HTTP/1.1 June 19998.1.2.2 PipeliningA client that supports persistent connections MAY "pipeline" itsrequests (i.e., send multiple requests without waiting for eachresponse). A server MUST send its responses to those requests in thesame order that the requests were received.Clients which assume persistent connections and pipeline immediatelyafter connection establishment SHOULD be prepared to retry theirconnection if the first pipelined attempt fails. If a client doessuch a retry, it MUST NOT pipeline before it knows the connection ispersistent. Clients MUST also be prepared to resend their requests ifthe server closes the connection before sending all of thecorresponding responses.Clients SHOULD NOT pipeline requests using non-idempotent methods ornon-idempotent sequences of methods (see section 9.1.2). Otherwise, apremature termination of the transport connection could lead toindeterminate results. A client wishing to send a non-idempotentrequest SHOULD wait to send that request until it has received theresponse status for the previous request.8.1.3 Proxy Servers