- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Fri, 24 May 1996 00:41:10 -0400
- To: "http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
- Cc: "jg@w3.org" <jg@w3.org>
These are my changes for making persistent connections the default
behavior. I have tried to keep the edits at a minimum and deliberately
_not_ changed the requirement of implementing persistent connections from
SHOULD to MUST as it does not affect the default behavior.
Please send comments to the list ASAP and sorry for the late arrival of
this edit.
Henrik
* * * * * * * * * *
13.4.1 SLUSHY: Entity Transmission Requirements
Editor's Note: The issues here around reliable transmission of large
entities to servers, particularly HTTP/1.0 servers, are complicated and
subtle, particularly since we'd like optimistic transmission to be the
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
normal situation. We would like it if we can redraft this section to be
simpler in the next draft
General requirements:
+ . HTTP/1.1 servers SHOULD maintain persistent connections and use
- . 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 doing a PUT-like method 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
- should immediately cease transmitting the body. If the body is
being sent using a "Chunked" encoding, a zero length chunk is used
to 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.
* * * * * * * * * *
17 Persistent Connections
17.1 Purpose
HTTP's greatest strength and its greatest weakness has been its
simplicity. 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 requires a client to make multiple requests
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 80]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
of the same server in a short amount of time. An excellent analysis of
these performance problems is available [30]; analysis and results from
a prototype implementation are in [33], [34].
Persistent HTTP connections have a number of advantages:
. By opening and closing fewer TCP connections, CPU time is saved,
and memory used for TCP protocol control blocks is also saved
. HTTP requests and responses can be pipe-lined on a connection.
Pipe-lining 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.
. 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.
. 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.
HTTP implementations SHOULD implement persistent connections.
+ A main 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
+ may assume that the server will maintain a persistent connection.
17.2 Overall Operation
+ Persistent connections provide a mechanism by which a client and a
+ server can negotiate the close of a TCP connection. This negotiation
+ takes place using the Connection header field. Once a close has been
+ negotiated, the client MUST not send any more requests on that
+ connection.
- Persistent connections provides a mechanism by which a client and a
- server can negotiate the use of a TCP connection for an extended
- conversation. This negotiation takes place using the Connection and
- Persist header fields. Once this option has been negotiated, the client
- can make multiple HTTP requests over a single transport connection.
17.2.1 Negotiation
+ An HTTP/1.1 server MAY assume that a HTTP/1.1 client maintains 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, it SHOULD send a Connection header
+ including the connection-token "Close".
+
+ 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".
+
+ If either the client or the server sends the "Close" token
+ in the Connection header, that request becomes the last one for the
+ connection.
- To request the use of persistent connections, a client sends a
- Connection header with a connection-token "Persist". If the server
- wishes to accept persistent connections, it will respond with the same
- connection-token. Both the client and server MUST send this connection-
- token with every request and response for the duration of the persistent
- connection. If either the client or the server omits the Persist token
- from the Connection header, that request becomes the last one for the
- connection.
+ Clients and servers SHOULD NOT assume that a persistent connection is
+ maintained for HTTP versions less than 1.1 unless it is explicitly
+ negotiated (See section 23.5.2.5 for more information on backwards
+ compatibility with HTTP/1.0 clients.)
- A server MUST NOT establish a persistent connection with an HTTP/1.0
- client that uses the above form of the Persist header due to problems
- with the interactions between HTTP/1.1 clients and HTTP/1.0 proxy
- servers. (See section 23.5.2.5 for more information on backwards
- compatibility with HTTP/1.0 clients.)
17.2.2 Pipe-lining
Clients and servers which support persistent connections MAY "pipe-line"
their requests and responses. When pipe-lining, a client will send
multiple requests without waiting for the responses. The server MUST
then send all of the responses in the same order that the requests were
made.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 81]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+ Clients which assume persistent connections and pipeline immediately
+ after connection establishment SHOULD be prepared to retry their
+ connection if the first pipe-lined attempt fails. If a client does
+ such a retry, it MUST NOT pipeline before it knows that the response
+ from a server does not contain a Connection header with the
+ connection-token "Close". Clients MUST also be prepared to resend
+ their requests if the server closes the connection before sending all
+ of the corresponding responses.
- A client MAY assume that a server supports persistent connections if the
- same server has accepted persistent connections within the past 24
- hours. Clients which assume persistent connections and pipeline
- immediately SHOULD be prepared to retry their connection if the first
- pipe-lined attempt fails. If a client does such a retry, it MUST NOT
- pipeline without first receiving an explicit Persist token from the
- server. Clients MUST also be prepared to resend their requests if the
- server closes the connection before sending all of the corresponding
- responses.
17.2.3 Delimiting Entity-Bodies
When using persistent connections, both the client and the server MUST
mark the exact endings of transmitted entity-bodies using one of the
following three techniques:
1. Send a Content-length field in the header with the exact number of
bytes in the entity-body.
2. Send the message using chunked Transfer Coding as described in
section 7.6. Chunked Transfer Coding allows the server to transmit
the data to the client a piece at a time while still communicating
an exact ending of the entity-body.
3. Close the transport connection after the entity body.
+ Sending the Content-length is the preferred technique. Chunked
+ encoding SHOULD be used when the size of the entity-body is not known
+ before beginning to transmit the entity-body. Finally, if neither 1
+ or 2 are possible then the connection SHOULD be closed. Note that the
+ last method does not work if the entity-body is part of a request.
- Sending the Content-length is the preferred technique. Chunked encoding
- SHOULD be used when the size of the entity-body is not known before
- beginning to transmit the entity-body. Finally, the connection MAY be
- closed and fall back to non-persistent connections, if neither 1 or 2
- are possible.
Clients and servers that support persistent connections MUST correctly
support receiving via all three techniques.
17.3 Proxy Servers
It is especially important that proxies correctly implement the
properties of the Connection header field as specified in 14.2.1.
The proxy server MUST negotiate 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.
A proxy server MUST NOT establish a persistent connection with an
HTTP/1.0 client.
17.4 Interaction with Security Protocols
It is expected that persistent connections will operate with both SHTTP
[31] and SSL [32]. When used in conjunction with SHTTP, the SHTTP
request is prepared normally and the persist connection-token is placed
in the outermost request block (the one containing the "Secure" method).
When used in conjunction with SSL, a SSL session is started as normal
and the first HTTP request made using SSL contains the persistent
connection header.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 82]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
17.5 Practical Considerations
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 of this time-out for either the
client or the server.
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. 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.
It is suggested that clients which 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 of 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.
* * * * * * * * * *
18.11 Connection
HTTP version 1.1 provides a new request and response header field called
"Connection". This header field allows the client and server to specify
options which should only exist over that particular connection and MUST
NOT be communicated by proxies over further connections. The connection
header field MAY have multiple tokens separated by commas (referred to
as connection-tokens).
HTTP version 1.1 proxies MUST parse the Connection header field and for
every connection-token in this field, remove a corresponding header
field from the request before the request is forwarded. The use of a
connection option is specified by the presence of a connection token in
the Connection header field, not by the corresponding additional header
field (which may not be present).
+ When a client or a server wishes to close a persistent connection it
+ SHOULD send a "Close" connection-token:
+
+ Connection: close
- When a client wishes to establish a persistent connection it MUST send a
- "Persist" connection-token:
-
- Connection: persist
The Connection header has the following grammar:
Connection-header = "Connection" ":" 1#(connection-token)
connection-token = token
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 96]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
* * * * * * * * * *
- 18.33 Persist
- When the Persist connection-token has been transmitted with a request or
- a response a Persist header field MAY also be included. The Persist
- header field takes the following form:
-
- Persist-header = "Persist" ":" 0#pers-param
-
- pers-param = param-name "=" word
- param-name = token
-
- The Persist header itself is optional, and is used only if a parameter
- is being sent. HTTP/1.1 does not define any parameters.
-
- If the Persist header is sent, the corresponding connection token MUST
- be transmitted. The Persist header MUST be ignored if received without
- the connection token.
* * * * * * * * * *
23.5.2.5 Compatibility with HTTP/1.0 Persistent Connections
+ Some clients and servers may wish to be compatible with some previous
+ implementations of persistent connections in HTTP/1.0 clients and
+ servers. Persistent connections in HTTP/1.0 must be explicitly
+ negotiated as they are not the default behavior. HTTP/1.0
+ implementations are faulty, and the new facilities in HTTP/1.1 are
+ designed to rectify these problems. The fear was that some existing
+ 1.0 clients may be sending Keep-Alive to a proxy server that doesn't
+ understand Connection, which would then erroneously forward
- Some clients and servers may wish to be compatible with some previous
- implementations of persistent connections in HTTP/1.0 clients and
- servers. These implementations are faulty, and the new facilities in
- HTTP/1.1 are designed to rectify these problems. The fear was that
- some existing 1.0 clients may be sending Keep-Alive to a proxy server
- that doesn't understand Connection, which would then erroneously forward
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 138]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
it to the next inbound server, which would establish the Keep-Alive
connection and result in a dead 1.0 proxy waiting for the close on the
response. The result is that 1.0 clients must be prevented from using
Keep-Alive when talking to proxies.
However, talking to proxies is the most important use of persistent
connections, so that is clearly unacceptable. Therefore, we need some
other mechanism for indicating a persistent connection is desired, which
is safe to use even when talking to an old proxy that ignores
Connection. As it turns out, there are two ways to accomplish that:
1.
Introduce a new keyword (persist) which is declared to be valid only
when received from an HTTP/1.1 message.
2.
Declare persistence to be the default for HTTP/1.1 messages and
introduce a new keyword (close) for declaring non-persistence.
The following describes the original, buggy form of persistent
connections.
When connecting to an origin server an HTTP client MAY send the Keep-
+ Alive connection-token:
- Alive connection-token in addition to the Persist connection-token:
+ Connection: Keep-Alive
- Connection: Keep-Alive,Persist
An HTTP/1.0 server would then respond with the Keep-Alive connection
token and the client may proceed with an HTTP/1.0 (or Keep-Alive)
persistent connection.
An HTTP/1.1 server may also establish persistent connections with
HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
However, a persistent connection with an HTTP/1.0 client cannot make use
of the chunked transfer-coding, and therefore MUST use a Content-Length
for marking the ending boundary of each Entity-Body.
A client MUST NOT send the Keep-Alive connection token to a proxy server
as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 for parsing
the Connection header field.
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA
Received on Thursday, 23 May 1996 21:42:21 UTC