HTTP messaging is independent of the underlying transport- or session-layer connection protocol(s). HTTP only presumes a reliable transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request and response structures onto the data units of an underlying transport protocol is outside the scope of this specification.
As described in [HTTP
], the specific connection protocols to be used for an HTTP interaction are determined by client configuration and the target URI. For example, the "http" URI scheme ([HTTP
]) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use a proxy via some other connection, port, or protocol.
HTTP implementations are expected to engage in connection management, which includes maintaining the state of current connections, establishing a new connection or reusing an existing connection, processing messages received on a connection, detecting connection failures, and closing each connection. Most clients maintain multiple connections in parallel, including more than one connection per server endpoint. Most servers are designed to maintain thousands of concurrent connections, while controlling request queues to enable fair use and detect denial-of-service attacks.
It is beyond the scope of this specification to describe how connections are established via various transport- or session-layer protocols. Each HTTP connection maps to one underlying transport connection.
HTTP/1.1 does not include a request identifier for associating a given request message with its corresponding one or more response messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made on the same connection. More than one response message per request only occurs when one or more informational responses (1xx; see [HTTP
]) precede a final response to the same request.
A client that has more than one outstanding request on a connection MUST
maintain a list of outstanding requests in the order sent and MUST
associate each received response message on that connection to the first outstanding request that has not yet received a final (non-1xx) response.
If a client receives data on a connection that doesn't have outstanding requests, the client MUST NOT
consider that data to be a valid response; the client SHOULD
close the connection, since message delimitation is now ambiguous, unless the data consists only of one or more CRLF (which can be discarded per Section 2.2
HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection. HTTP implementations SHOULD
support persistent connections.
A recipient determines whether a connection is persistent or not based on the protocol version and Connection header field ([HTTP
]) in the most recently received message, if any:
If the "close" connection option is present (Section 9.6), the connection will not persist after the current response; else,
If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,
If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, either the recipient is not a proxy or the message is a response, and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise,
The connection will close after the current response.
A client that does not support persistent connections MUST
send the "close
" connection option in every request message.
A server that does not support persistent connections MUST
send the "close
" connection option in every response message that does not have a 1xx (Informational) status code.
A client MAY
send additional requests on a persistent connection until it sends or receives a "close
" connection option or receives an HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 6
. A server MUST
read the entire request message body or close the connection after sending its response; otherwise, the remaining data on a persistent connection would be misinterpreted as the next request. Likewise, a client MUST
read the entire response message body if it intends to reuse the same connection for a subsequent request.
A proxy server MUST NOT
maintain a persistent connection with an HTTP/1.0 client (see Appendix C.2.2
for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
See Appendix C.2.2
for more information on backwards compatibility with HTTP/1.0 clients.
Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from asynchronous close events. The conditions under which a client can automatically retry a sequence of outstanding requests are defined in [HTTP
A client that supports persistent connections MAY
"pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MAY
process a sequence of pipelined requests in parallel if they all have safe methods ([HTTP
]), but it MUST
send the corresponding responses in the same order that the requests were received.
A client that pipelines requests SHOULD
retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client MUST NOT
pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset problem described in Section 9.6
Idempotent methods ([HTTP
]) are significant to pipelining because they can be automatically retried after a connection failure. A user agent SHOULD NOT
pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
An intermediary that receives pipelined requests MAY
pipeline those requests when forwarding them inbound, since it can rely on the outbound user agent(s) to determine what requests can be safely pipelined. If the inbound connection fails before receiving a response, the pipelining intermediary MAY
attempt to retry a sequence of requests that have yet to receive a response if the requests all have idempotent methods; otherwise, the pipelining intermediary SHOULD
forward any received responses and then close the corresponding outbound connection(s) so that the outbound user agent(s) can recover accordingly.
A client ought to limit the number of simultaneous open connections that it maintains to a given server.
Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.
Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant server-side processing and/or transfers very large content would block subsequent requests on the same connection. However, each connection consumes server resources.
Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger numbers of connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used.
Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive number of open connections from a single client.
Servers will usually have some timeout 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 proxy server. The use of persistent connections places no requirements on the length (or existence) of this timeout for either the client or the server.
A client or server that wishes to time out SHOULD
issue a graceful close on the connection. Implementations SHOULD
constantly monitor open connections for a received closure signal and respond to it as appropriate, since prompt closure of both sides of a connection enables allocated system resources to be reclaimed.
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.
A server SHOULD
sustain persistent connections, when possible, and allow the underlying transport's flow-control mechanisms to resolve temporary overloads rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network congestion or server load.
A client sending a message body SHOULD
monitor the network connection for an error response while it is transmitting the request. If the client sees a response that indicates the server does not wish to receive the message body and is closing the connection, the client SHOULD
immediately cease transmitting the body and close its side of the connection.
The "close" connection option is defined as a signal that the sender will close this connection after completion of the response. A sender SHOULD
send a Connection header field ([HTTP
]) containing the "close" connection option when it intends to close a connection. For example,
as a request header field indicates that this is the last request that the client will send on this connection, while in a response, the same field indicates that the server is going to close this connection after the response message is complete.
Note that the field name "Close" is reserved, since using that name as a header field might conflict with the "close" connection option.
A client that sends a "close" connection option MUST NOT
send further requests on that connection (after the one containing the "close") and MUST
close the connection after reading the final response message corresponding to this request.
A server that receives a "close" connection option MUST
initiate closure of the connection (see below) after it sends the final response to the request that contained the "close" connection option. The server SHOULD
send a "close" connection option in its final response on that connection. The server MUST NOT
process any further requests received on that connection.
A server that sends a "close" connection option MUST
initiate closure of the connection (see below) after it sends the response containing the "close" connection option. The server MUST NOT
process any further requests received on that connection.
A client that receives a "close" connection option MUST
cease sending requests on that connection and close the connection after reading the response message containing the "close" connection option; if additional pipelined requests had been sent on the connection, the client SHOULD NOT
assume that they will be processed by the server.
If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able to read the last HTTP response. If the server receives additional data from the client on a fully closed connection, such as another request sent by the client before receiving the server's response, the server's TCP stack will send a reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they can be read and interpreted by the client's HTTP parser.
To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by closing only the write side of the read/write connection. The server then continues to read from the connection until it receives a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection.
It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.
Note that a TCP connection that is half-closed by the client does not delimit a request message, nor does it imply that the client is no longer interested in a response. In general, transport signals cannot be relied upon to signal edge cases, since HTTP/1.1 is independent of transport.
Conceptually, HTTP/TLS is simply sending HTTP messages over a connection secured via TLS [TLS13
The HTTP client also acts as the TLS client. It initiates a connection to the server on the appropriate port and sends the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished, the client may then initiate the first HTTP request. All HTTP data MUST
be sent as TLS "application data" but is otherwise treated like a normal connection for HTTP (including potential reuse as a persistent connection).
TLS uses an exchange of closure alerts prior to (non-error) connection closure to provide secure connection closure; see [TLS13
]. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection.
When an implementation knows that it has sent or received all the message data that it cares about, typically by detecting HTTP message boundaries, it might generate an "incomplete close" by sending a closure alert and then closing the connection without waiting to receive the corresponding closure alert from its peer.
An incomplete close does not call into question the security of the data already received, but it could indicate that subsequent data might have been truncated. As TLS is not directly aware of HTTP message framing, it is necessary to examine the HTTP data itself to determine whether messages are complete. Handling of incomplete messages is defined in Section 8
When encountering an incomplete close, a client SHOULD
treat as completed all requests for which it has received either
as much data as specified in the Content-Length header field or
the terminal zero-length chunk (when Transfer-Encoding of chunked is used).
A response that has neither chunked transfer coding nor Content-Length is complete only if a valid closure alert has been received. Treating an incomplete message as complete could expose implementations to attack.
A client detecting an incomplete close SHOULD
send a closure alert before closing the connection. Clients that do not expect to receive any more data MAY
choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side.
be prepared to receive an incomplete close from the client, since the client can often locate the end of server data.
attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers MAY
close the connection after sending the closure alert, thus generating an incomplete close on the client side.