When a client or server wishes to time-out it SHOULD issue a graceful
   close on the transport connection. Clients and servers SHOULD both
   constantly watch for the other side of the transport close, and
   respond to it as appropriate. If a client or server does not detect
   the other side's close promptly it could cause unnecessary resource
   drain on the network.

   A client, server, or proxy MAY close the transport connection at any
   time. For example, a client MAY have started to send a new request at
   the same time that the server has decided to close the "idle"
   connection. From the server's point of view, the connection is being
   closed while it was idle, but from the client's point of view, a
   request is in progress.

   This means that clients, servers, and proxies MUST be able to recover
   from asynchronous close events. Client software SHOULD reopen the
   transport connection and retransmit the aborted request without user
   interaction so long as the request method is idempotent (see section




 
RFC 2068                        HTTP/1.1                    January 1997


   9.1.2); other methods MUST NOT be automatically retried, although
   user agents MAY offer a human operator the choice of retrying the
   request.

   However, this automatic retry SHOULD NOT be repeated if the second
   request fails.

   Servers SHOULD always respond to at least one request per connection,
   if at all possible. Servers SHOULD NOT close a connection in the
   middle of transmitting a response, unless a network or client failure
   is suspected.

   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD maintain AT MOST 2 connections with any
   server or proxy. A proxy SHOULD use up to 2*N connections to another
   server or proxy, where N is the number of simultaneously active
   users. These guidelines are intended to improve HTTP response times
   and avoid congestion of the Internet or other networks.

8.2 Message Transmission Requirements

General requirements:

o  HTTP/1.1 servers SHOULD maintain persistent connections and use
   TCP's flow control mechanisms to resolve temporary overloads,
   rather than terminating connections with the expectation that
   clients will retry. The latter technique can exacerbate network
   congestion.

o  An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
   the network connection for an error status while it is transmitting
   the request. If the client sees an error status, it SHOULD
   immediately cease transmitting the body. If the body is being sent
   using a "chunked" encoding (section 3.6), a zero length chunk and
   empty footer MAY be used to prematurely mark the end of the
   message. If the body was preceded by a Content-Length header, the
   client MUST close the connection.

o  An HTTP/1.1 (or later) client MUST be prepared to accept a 100
   (Continue) status followed by a regular response.

o  An HTTP/1.1 (or later) server that receives a request from a
   HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
   response; it SHOULD either wait for the request to be completed
   normally (thus avoiding an interrupted request) or close the
   connection prematurely.





 
RFC 2068                        HTTP/1.1                    January 1997


   Upon receiving a method subject to these requirements from an
   HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
   respond with 100 (Continue) status and continue to read from the
   input stream, or respond with an error status. If it responds with an
   error status, it MAY close the transport (TCP) connection or it MAY
   continue to read and discard the rest of the request. It MUST NOT
   perform the requested method if it returns an error status.

   Clients SHOULD remember the version number of at least the most
   recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
   later response from the server, and it sees the connection close
   before receiving any status from the server, the client SHOULD retry
   the request without user interaction so long as the request method is
   idempotent (see section 9.1.2); other methods MUST NOT be
   automatically retried, although user agents MAY offer a human
   operator the choice of retrying the request.. If the client does
   retry the request, the client