Connected: An Internet Encyclopedia
8.2 Message Transmission Requirements
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 2068
Up:
8 Connections
Prev: 8.1.4 Practical Considerations
Next: 9 Method Definitions
8.2 Message Transmission Requirements
8.2 Message Transmission Requirements
General requirements:
- 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.
- 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.
- An HTTP/1.1 (or later) client MUST be prepared to accept a 100
(Continue) status followed by a regular response.
- 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.
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
- MUST first send the request header fields, and then
- 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:
- Initiate a new connection to the server
- Transmit the request-headers
- 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.
- Compute T = R * (2**N), where N is the number of previous retries
of this request.
- Wait either for an error response from the server, or for T seconds
(whichever comes first)
- If no error response is received, after T seconds transmit the body
of the request.
- 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
- MUST NOT continue and
- 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).
Next: 9 Method Definitions
Connected: An Internet Encyclopedia
8.2 Message Transmission Requirements