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.




Fielding, et. al.           Standards Track                    [Page 46]

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

     o  MUST first send the request header fields, and then

     o  MUST wait for the server to respond with either a 100 (Continue)
        response, in which case the client should continue, or with an
        error status.

   If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
   the server, it should assume that the server implements HTTP/1.0 or
   older and will not use the 100 (Continue) response. If in this case
   the client sees the connection close before receiving any status from
   the server, the client SHOULD retry the request. If the client does
   retry the request to this HTTP/1.0 server, it should use the
   following "binary exponential backoff" algorithm to be assured of
   obtaining a reliable response:

  1. Initiate a new connection to the server

  2. Transmit the request-headers

  3. Initialize a variable R to the estimated round-trip time to the
     server (e.g., based on the time it took to establish the
     connection), or to a constant value of 5 seconds if the round-trip
     time is not available.

  4. Compute T = R * (2**N), where N is the number of previous retries
     of this request.

  5. Wait either for an error response from the server, or for T seconds
     (whichever comes first)




Fielding, et. al.           Standards Track                    [Page 47]

RFC 2068                        HTTP/1.1                    January 1997


  6. If no error response is received, after T seconds transmit the body
     of the request.

  7. If client sees that the connection is closed prematurely, repeat
     from step 1 until the request is accepted, an error response is
     received, or the user becomes impatient and terminates the retry
     process.

   No matter what the server version, if an error status is received,
   the client

  o  MUST NOT continue and

  o  MUST close the connection if it has not completed sending the
     message.

   An HTTP/1.1 (or later) client that sees the connection close after
   receiving a 100 (Continue) but before receiving any other status
   SHOULD retry the request, and need not wait for 100 (Continue)
   response (but MAY do so if this simplifies the implementation).