You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
357 lines
18 KiB
357 lines
18 KiB
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns='http://www.w3.org/1999/xhtml'>
|
|
<head><title>HTTP/1.1: Connections</title></head>
|
|
<body><address>part of <a rev='Section' href='rfc2616.html'>Hypertext Transfer Protocol -- HTTP/1.1</a><br />
|
|
RFC 2616 Fielding, et al.</address>
|
|
<h2><a id='sec8'>8</a> Connections</h2>
|
|
<h3><a id='sec8.1'>8.1</a> Persistent Connections</h3>
|
|
<h3><a id='sec8.1.1'>8.1.1</a> Purpose</h3>
|
|
<p>
|
|
Prior to persistent connections, a separate TCP connection was
|
|
established to fetch each URL, increasing the load on HTTP servers
|
|
and causing congestion on the Internet. The use of inline images and
|
|
other associated data often require a client to make multiple
|
|
requests of the same server in a short amount of time. Analysis of
|
|
these performance problems and results from a prototype
|
|
implementation are available <a rel='bibref' href='rfc2616-sec17.html#bib26'>[26]</a> <a rel='bibref' href='rfc2616-sec17.html#bib30'>[30]</a>. Implementation experience and
|
|
measurements of actual HTTP/1.1 (RFC 2068) implementations show good
|
|
results <a rel='bibref' href='rfc2616-sec17.html#bib39'>[39]</a>. Alternatives have also been explored, for example,
|
|
T/TCP <a rel='bibref' href='rfc2616-sec17.html#bib27'>[27]</a>.
|
|
</p>
|
|
<p>
|
|
Persistent HTTP connections have a number of advantages:
|
|
</p>
|
|
<pre> - By opening and closing fewer TCP connections, CPU time is saved
|
|
in routers and hosts (clients, servers, proxies, gateways,
|
|
tunnels, or caches), and memory used for TCP protocol control
|
|
blocks can be saved in hosts.
|
|
</pre>
|
|
<pre> - HTTP requests and responses can be pipelined on a connection.
|
|
Pipelining allows a client to make multiple requests without
|
|
waiting for each response, allowing a single TCP connection to
|
|
be used much more efficiently, with much lower elapsed time.
|
|
</pre>
|
|
<pre> - Network congestion is reduced by reducing the number of packets
|
|
caused by TCP opens, and by allowing TCP sufficient time to
|
|
determine the congestion state of the network.
|
|
</pre>
|
|
<pre> - Latency on subsequent requests is reduced since there is no time
|
|
spent in TCP's connection opening handshake.
|
|
</pre>
|
|
<pre> - HTTP can evolve more gracefully, since errors can be reported
|
|
without the penalty of closing the TCP connection. Clients using
|
|
future versions of HTTP might optimistically try a new feature,
|
|
but if communicating with an older server, retry with old
|
|
semantics after an error is reported.
|
|
</pre>
|
|
<p>
|
|
HTTP implementations SHOULD implement persistent connections.
|
|
</p>
|
|
<h3><a id='sec8.1.2'>8.1.2</a> Overall Operation</h3>
|
|
<p>
|
|
A significant difference between HTTP/1.1 and earlier versions of
|
|
HTTP is that persistent connections are the default behavior of any
|
|
HTTP connection. That is, unless otherwise indicated, the client
|
|
SHOULD assume that the server will maintain a persistent connection,
|
|
even after error responses from the server.
|
|
</p>
|
|
<p>
|
|
Persistent connections provide a mechanism by which a client and a
|
|
server can signal the close of a TCP connection. This signaling takes
|
|
place using the Connection header field (section <a rel='xref' href='rfc2616-sec14.html#sec14.10'>14.10</a>). Once a close
|
|
has been signaled, the client MUST NOT send any more requests on that
|
|
connection.
|
|
</p>
|
|
<h3><a id='sec8.1.2.1'>8.1.2.1</a> Negotiation</h3>
|
|
<p>
|
|
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
|
|
maintain a persistent connection unless a Connection header including
|
|
the connection-token "close" was sent in the request. If the server
|
|
chooses to close the connection immediately after sending the
|
|
response, it SHOULD send a Connection header including the
|
|
connection-token close.
|
|
</p>
|
|
<p>
|
|
An HTTP/1.1 client MAY expect a connection to remain open, but would
|
|
decide to keep it open based on whether the response from a server
|
|
contains a Connection header with the connection-token close. In case
|
|
the client does not want to maintain a connection for more than that
|
|
request, it SHOULD send a Connection header including the
|
|
connection-token close.
|
|
</p>
|
|
<p>
|
|
If either the client or the server sends the close token in the
|
|
Connection header, that request becomes the last one for the
|
|
connection.
|
|
</p>
|
|
<p>
|
|
Clients and servers SHOULD NOT assume that a persistent connection is
|
|
maintained for HTTP versions less than 1.1 unless it is explicitly
|
|
signaled. See section <a rel='xref' href='rfc2616-sec19.html#sec19.6.2'>19.6.2</a> for more information on backward
|
|
compatibility with HTTP/1.0 clients.
|
|
</p>
|
|
<p>
|
|
In order to remain persistent, all messages on the connection MUST
|
|
have a self-defined message length (i.e., one not defined by closure
|
|
of the connection), as described in section <a rel='xref' href='rfc2616-sec4.html#sec4.4'>4.4</a>.
|
|
</p>
|
|
<h3><a id='sec8.1.2.2'>8.1.2.2</a> Pipelining</h3>
|
|
<p>
|
|
A client that supports persistent connections MAY "pipeline" its
|
|
requests (i.e., send multiple requests without waiting for each
|
|
response). A server MUST send its responses to those requests in the
|
|
same order that the requests were received.
|
|
</p>
|
|
<p>
|
|
Clients which assume persistent connections and pipeline immediately
|
|
after connection establishment SHOULD be prepared to retry their
|
|
connection if the first pipelined attempt fails. If a client does
|
|
such a retry, it MUST NOT pipeline before it knows the connection is
|
|
persistent. Clients MUST also be prepared to resend their requests if
|
|
the server closes the connection before sending all of the
|
|
corresponding responses.
|
|
</p>
|
|
<p>
|
|
Clients SHOULD NOT pipeline requests using non-idempotent methods or
|
|
non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
|
|
premature termination of the transport connection could lead to
|
|
indeterminate results. A client wishing to send a non-idempotent
|
|
request SHOULD wait to send that request until it has received the
|
|
response status for the previous request.
|
|
</p>
|
|
<h3><a id='sec8.1.3'>8.1.3</a> Proxy Servers</h3>
|
|
<p>
|
|
It is especially important that proxies correctly implement the
|
|
properties of the Connection header field as specified in section
|
|
<a rel='xref' href='rfc2616-sec14.html#sec14.10'>14.10</a>.
|
|
</p>
|
|
<p>
|
|
The proxy server MUST signal persistent connections separately with
|
|
its clients and the origin servers (or other proxy servers) that it
|
|
connects to. Each persistent connection applies to only one transport
|
|
link.
|
|
</p>
|
|
<p>
|
|
A proxy server MUST NOT establish a HTTP/1.1 persistent connection
|
|
with an HTTP/1.0 client (but see RFC 2068 [33] for information and
|
|
discussion of the problems with the Keep-Alive header implemented by
|
|
many HTTP/1.0 clients).
|
|
</p>
|
|
<h3><a id='sec8.1.4'>8.1.4</a> Practical Considerations</h3>
|
|
<p>
|
|
Servers will usually have some time-out value beyond which they will
|
|
no longer maintain an inactive connection. Proxy servers might make
|
|
this a higher value since it is likely that the client will be making
|
|
more connections through the same server. The use of persistent
|
|
connections places no requirements on the length (or existence) of
|
|
this time-out for either the client or the server.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
A client, server, or proxy MAY close the transport connection at any
|
|
time. For example, a client might 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.
|
|
</p>
|
|
<p>
|
|
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 sequence of requests
|
|
without user interaction so long as the request sequence is
|
|
idempotent (see section <a rel='xref' href='rfc2616-sec9.html#sec9.1.2'>9.1.2</a>). Non-idempotent methods or sequences
|
|
MUST NOT be automatically retried, although user agents MAY offer a
|
|
human operator the choice of retrying the request(s). Confirmation by
|
|
user-agent software with semantic understanding of the application
|
|
MAY substitute for user confirmation. The automatic retry SHOULD NOT
|
|
be repeated if the second sequence of requests fails.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
Clients that use persistent connections SHOULD limit the number of
|
|
simultaneous connections that they maintain to a given server. A
|
|
single-user client SHOULD NOT maintain more than 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.
|
|
</p>
|
|
<h3><a id='sec8.2'>8.2</a> Message Transmission Requirements</h3>
|
|
<h3><a id='sec8.2.1'>8.2.1</a> Persistent Connections and Flow Control</h3>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<h3><a id='sec8.2.2'>8.2.2</a> Monitoring Connections for Error Status Messages</h3>
|
|
<p>
|
|
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 <a rel='xref' href='rfc2616-sec3.html#sec3.6'>3.6</a>), a zero length chunk and
|
|
empty trailer 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.
|
|
</p>
|
|
<h3><a id='sec8.2.3'>8.2.3</a> Use of the 100 (Continue) Status</h3>
|
|
<p>
|
|
The purpose of the 100 (Continue) status (see section <a rel='xref' href='rfc2616-sec10.html#sec10.1.1'>10.1.1</a>) is to
|
|
allow a client that is sending a request message with a request body
|
|
to determine if the origin server is willing to accept the request
|
|
(based on the request headers) before the client sends the request
|
|
body. In some cases, it might either be inappropriate or highly
|
|
inefficient for the client to send the body if the server will reject
|
|
the message without looking at the body.
|
|
</p>
|
|
<p>
|
|
Requirements for HTTP/1.1 clients:
|
|
</p>
|
|
<pre> - If a client will wait for a 100 (Continue) response before
|
|
sending the request body, it MUST send an Expect request-header
|
|
field (section <a rel='xref' href='rfc2616-sec14.html#sec14.20'>14.20</a>) with the "100-continue" expectation.
|
|
</pre>
|
|
<pre> - A client MUST NOT send an Expect request-header field (section
|
|
<a rel='xref' href='rfc2616-sec14.html#sec14.20'>14.20</a>) with the "100-continue" expectation if it does not intend
|
|
to send a request body.
|
|
</pre>
|
|
<p>
|
|
Because of the presence of older implementations, the protocol allows
|
|
ambiguous situations in which a client may send "Expect: 100-
|
|
continue" without receiving either a 417 (Expectation Failed) status
|
|
or a 100 (Continue) status. Therefore, when a client sends this
|
|
header field to an origin server (possibly via a proxy) from which it
|
|
has never seen a 100 (Continue) status, the client SHOULD NOT wait
|
|
for an indefinite period before sending the request body.
|
|
</p>
|
|
<p>
|
|
Requirements for HTTP/1.1 origin servers:
|
|
</p>
|
|
<pre> - Upon receiving a request which includes an Expect request-header
|
|
field with the "100-continue" expectation, an origin server MUST
|
|
either respond with 100 (Continue) status and continue to read
|
|
from the input stream, or respond with a final status code. The
|
|
origin server MUST NOT wait for the request body before sending
|
|
the 100 (Continue) response. If it responds with a final status
|
|
code, it MAY close the transport connection or it MAY continue
|
|
</pre>
|
|
<pre> to read and discard the rest of the request. It MUST NOT
|
|
perform the requested method if it returns a final status code.
|
|
</pre>
|
|
<pre> - An origin server SHOULD NOT send a 100 (Continue) response if
|
|
the request message does not include an Expect request-header
|
|
field with the "100-continue" expectation, and MUST NOT send a
|
|
100 (Continue) response if such a request comes from an HTTP/1.0
|
|
(or earlier) client. There is an exception to this rule: for
|
|
compatibility with RFC 2068, a server MAY send a 100 (Continue)
|
|
status in response to an HTTP/1.1 PUT or POST request that does
|
|
not include an Expect request-header field with the "100-
|
|
continue" expectation. This exception, the purpose of which is
|
|
to minimize any client processing delays associated with an
|
|
undeclared wait for 100 (Continue) status, applies only to
|
|
HTTP/1.1 requests, and not to requests with any other HTTP-
|
|
version value.
|
|
</pre>
|
|
<pre> - An origin server MAY omit a 100 (Continue) response if it has
|
|
already received some or all of the request body for the
|
|
corresponding request.
|
|
</pre>
|
|
<pre> - An origin server that sends a 100 (Continue) response MUST
|
|
ultimately send a final status code, once the request body is
|
|
received and processed, unless it terminates the transport
|
|
connection prematurely.
|
|
</pre>
|
|
<pre> - If an origin server receives a request that does not include an
|
|
Expect request-header field with the "100-continue" expectation,
|
|
the request includes a request body, and the server responds
|
|
with a final status code before reading the entire request body
|
|
from the transport connection, then the server SHOULD NOT close
|
|
the transport connection until it has read the entire request,
|
|
or until the client closes the connection. Otherwise, the client
|
|
might not reliably receive the response message. However, this
|
|
requirement is not be construed as preventing a server from
|
|
defending itself against denial-of-service attacks, or from
|
|
badly broken client implementations.
|
|
</pre>
|
|
<p>
|
|
Requirements for HTTP/1.1 proxies:
|
|
</p>
|
|
<pre> - If a proxy receives a request that includes an Expect request-
|
|
header field with the "100-continue" expectation, and the proxy
|
|
either knows that the next-hop server complies with HTTP/1.1 or
|
|
higher, or does not know the HTTP version of the next-hop
|
|
server, it MUST forward the request, including the Expect header
|
|
field.
|
|
</pre>
|
|
<pre> - If the proxy knows that the version of the next-hop server is
|
|
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
|
|
respond with a 417 (Expectation Failed) status.
|
|
</pre>
|
|
<pre> - Proxies SHOULD maintain a cache recording the HTTP version
|
|
numbers received from recently-referenced next-hop servers.
|
|
</pre>
|
|
<pre> - A proxy MUST NOT forward a 100 (Continue) response if the
|
|
request message was received from an HTTP/1.0 (or earlier)
|
|
client and did not include an Expect request-header field with
|
|
the "100-continue" expectation. This requirement overrides the
|
|
general rule for forwarding of 1xx responses (see section <a rel='xref' href='rfc2616-sec10.html#sec10.1'>10.1</a>).
|
|
</pre>
|
|
<h3><a id='sec8.2.4'>8.2.4</a> Client Behavior if Server Prematurely Closes Connection</h3>
|
|
<p>
|
|
If an HTTP/1.1 client sends a request which includes a request body,
|
|
but which does not include an Expect request-header field with the
|
|
"100-continue" expectation, and if the client is not directly
|
|
connected to an HTTP/1.1 origin server, and if the client sees the
|
|
connection close before receiving any status from the server, the
|
|
client SHOULD retry the request. If the client does retry this
|
|
request, it MAY use the following "binary exponential backoff"
|
|
algorithm to be assured of obtaining a reliable response:
|
|
</p>
|
|
<pre> 1. Initiate a new connection to the server
|
|
</pre>
|
|
<pre> 2. Transmit the request-headers
|
|
</pre>
|
|
<pre> 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.
|
|
</pre>
|
|
<pre> 4. Compute T = R * (2**N), where N is the number of previous
|
|
retries of this request.
|
|
</pre>
|
|
<pre> 5. Wait either for an error response from the server, or for T
|
|
seconds (whichever comes first)
|
|
</pre>
|
|
<pre> 6. If no error response is received, after T seconds transmit the
|
|
body of the request.
|
|
</pre>
|
|
<pre> 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.
|
|
</pre>
|
|
<p>
|
|
If at any point an error status is received, the client
|
|
</p>
|
|
<pre> - SHOULD NOT continue and
|
|
</pre>
|
|
<pre> - SHOULD close the connection if it has not completed sending the
|
|
request message.
|
|
</pre>
|
|
</body></html>
|