1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
connection
Click on the red underlined text to get to the source
... not sufficiently take into consideration the effects of hierarchical
proxies, caching, the need for persistent connections, and virtual
hosts. In addition, the proliferation of incompletely-implemented
applications calling themselves "HTTP/1.0 ...
... HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in section 4 and
transmitted via the connection.
request
...
... client
A program that establishes connections for the purpose of sending
requests.
...
...
server
An application program that accepts connections in order to
service requests by sending back responses. Any given program may
...
... terms refers only to the role being performed by the program for a
particular connection, rather than to the program's capabilities
in general. Likewise, any server may act as an origin server,
proxy ...
... tunnel
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
...
... HTTP request. The tunnel ceases to exist when both
ends of the relayed connections are closed.
cache ...
... modifiers, client information, and possible body content over a
connection with a server. The server responds with a status line,
including the message's protocol version and a success or error code ...
... user agent and consists of
a request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v)
between the user agent (UA ...
... necessary, translating the requests to the underlying server's
protocol. A tunnel acts as a relay point between two connections
without changing the messages; tunnels are used when the
...
... user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections.
This distinction is important because some HTTP communication options
...
... This distinction is important because some HTTP communication options
may apply only to the connection with the nearest, non-tunnel
neighbor ...
... neighbor, only to the end-points of the chain, or to all connections
along the chain. Although the diagram is linear, each participant
may be engaged in multiple, simultaneous communications. For example,
...
...
In HTTP/1.0, most implementations used a new connection for each
request/response exchange. In HTTP/1.1 ...
... request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response exchanges, although connections ...
... connection may be used for
one or more request/response exchanges, although connections may be
closed for a variety of reasons (see section 8.1).
...
... semantics
are that the identified resource is located at the server listening
for TCP connections on that port of that host, and the Request-URI ...
... entity-body with a
transfer-coding it does not understand SHOULD return 501
(Unimplemented), and close the connection. A server MUST NOT send
transfer-codings to an HTTP/1.0 client ...
...
5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that
...
... 5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a response.)
...
... header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.19
| Pragma ; Section 14.32
...
... to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
...
... Connections ...
... Persistent Connections ...
...
Prior to persistent connections, a separate TCP connection was
established to fetch each URL ...
...
Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the load on HTTP ...
...
Persistent HTTP connections have a number of advantages:
o By opening and closing fewer TCP connections ...
... connections have a number of advantages:
o By opening and closing fewer TCP connections, CPU time is saved,
and memory used for TCP ...
... TCP protocol control blocks is also saved.
o HTTP requests and responses can be pipelined on a connection.
Pipelining allows a client ...
... 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.
...
... o HTTP can evolve more gracefully; since errors can be reported
without the penalty of closing the TCP connection. Clients using
future versions ...
...
HTTP implementations SHOULD implement persistent connections.
...
... versions of
HTTP is that persistent connections are the default behavior of any
HTTP connection ...
... 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 ...
... connection. That is, unless otherwise indicated, the client may
assume that the server will maintain a persistent connection.
Persistent connections ...
... connection.
Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection ...
... 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 ...
... TCP connection. This signaling takes
place using the Connection header field. Once a close has been
signaled, the client ...
... signaled, the client MUST not send any more requests on that
connection.
...
... HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including
...
... client intends to
maintain a persistent connection unless a Connection header including
the connection ...
... Connection header including
the connection-token "close" was sent in the request. If the server
chooses to close the connection ...
... 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 ...
... chooses to close the connection immediately after sending the
response, it SHOULD send a Connection header including the
connection ...
... 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 ...
... 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 ...
... token close. In case
the client does not want to maintain a connection for more than that
request, it SHOULD send a Connection header ...
... client does not want to maintain a connection for more than that
request, it SHOULD send a Connection header including the
connection ...
... client or the server sends the close token in the
Connection header, that request becomes the last one for the
connection ...
... Connection header, that request becomes the last one for the
connection.
Clients and servers ...
...
Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP versions ...
... clients.
In order to remain persistent, all messages on the connection must
have a self-defined message length (i.e., one not defined by closure
...
... have a self-defined message length (i.e., one not defined by closure
of the connection), as described in section 4.4.
...
...
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
...
...
Clients which assume persistent connections and pipeline immediately
after connection establishment SHOULD be prepared to retry their
...
... 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 ...
... 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 ...
... 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
...
... persistent. Clients MUST also be prepared to resend their requests if
the server closes the connection before sending all of the
corresponding responses.
...
... 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 signal persistent connections separately with
its clients and the origin servers (or other proxy servers ...
... clients and the origin servers (or other proxy servers) that it
connects to. Each persistent connection applies to only one transport
link ...
...
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 ...
... 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 ...
... 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 ...
... 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 ...
... 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
...
... 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 ...
... 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
...
... asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted request without user
interaction so long as the request method is idempotent (see section
...
... 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
...
... 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 ...
...
Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
...
... Clients that 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 ...
... connections that they maintain to a given server. A
single-user client SHOULD maintain AT MOST 2 connections with any
server or proxy. A proxy ...
... 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 ...
... flow control mechanisms to resolve temporary overloads,
rather than terminating connections with the expectation that
clients will retry. The latter technique can exacerbate network ...
... client sending a message-body SHOULD monitor
the network connection for an error status while it is transmitting
...
... response; it SHOULD either wait for the request to be completed
normally (thus avoiding an interrupted request) or close the
connection prematurely.
Upon receiving ...
... 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 ...
... 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 ...
... 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 ...
... obtaining a reliable response:
1. Initiate a new connection to the server
2. Transmit the request-headers ...
... 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.
...
...
7. If client sees that the connection is closed prematurely, repeat
from step 1 until the request is accepted, an error response is
...
... 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 ...
... message header field (section 14.41), for a
change in the application protocol being used on this connection. The
server will switch protocols to those defined by the response's
...
... batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist
until the process is completed. The entity returned with this
...
... client acknowledges
receipt of the packet(s) containing the response, before the server
closes the input connection. If the client continues sending data
to the server after the close, the server's TCP ...
... entity is larger than the server is willing or able to process. The
server may close the connection to prevent the client from continuing
the request.
...
... server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
...
... Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies ...
... body, either because the request included one or more Range
specifications, or because a connection was broken prematurely. After
several such transfers, a cache may have received several ranges ...
... Connection ...
... header field allows the sender to specify
options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections ...
... HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection ...
... Connection header field before a
message is forwarded and, for each connection-token in this field,
remove ...
... remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of
...
... token. Connection options are signaled by the presence of
a connection-token in the Connection header field ...
... a connection-token in the Connection header field, not by any
corresponding additional header ...
... additional header
field may not be sent if there are no parameters associated with that
connection option. HTTP/1.1 defines the "close" connection option
...
... connection option. HTTP/1.1 defines the "close" connection option
for the sender to signal that the connection ...
... connection option
for the sender to signal that the connection will be closed after
completion of the response. For example,
...
... completion of the response. For example,
Connection: close
in either the request or the response header fields ...
... in either the request or the response header fields indicates that
the connection should not be considered `persistent' (section 8.1)
after the current request/response is complete.
...
...
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message.
...
... HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message.
...
... GMT
If a message is received via direct connection with the user agent
(in the case of requests) or the origin server (in the case of
...
... Authenticate header field applies
only to the current connection and SHOULD NOT be passed on to
downstream clients ...
... the client (i.e., the nearest neighbor in a chain of connections). If
the response passes through a proxy, the proxy ...
... application-layer
protocols upon the existing transport-layer connection. Upgrade
cannot be used to insist on a protocol change; its acceptance and use
by the server ...
...
The Upgrade header field only applies to the immediate connection.
Therefore, the upgrade keyword MUST be supplied within a Connection
...
... header field only applies to the immediate connection.
Therefore, the upgrade keyword MUST be supplied within a Connection
header field (section 14.10) whenever Upgrade is present in an
...
... header field cannot be used to indicate a switch to a
protocol on a different connection. For that purpose, it is more
appropriate to use a 301, 302, 303, or 305 redirection response.
...
... gateways or CGI scripts. In particular
it is very dangerous for a server to simply turn over a connection to
a gateway since that gateway ...
... a gateway since that gateway can then use the persistent connection
mechanism to engage in multiple transactions with the client ...
... MIME. These differences were carefully chosen to optimize
performance over binary connections, to allow greater freedom in the
use of new media types, to make date comparisons easier, and to
...
...
For most implementations of HTTP/1.0, each connection is established
by the client prior to the request and closed by the server ...
... 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 ...
... 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 ...
... HTTP/1.0
experimental implementations of persistent connections are faulty,
and the new facilities in HTTP/1.1 are designed to rectify these
...
... Keep-Alive to a proxy server that doesn't understand
Connection, which would then erroneously forward it to the next
inbound server, which would establish the Keep-Alive connection ...
... Connection, which would then erroneously forward it to the next
inbound server, which would establish the Keep-Alive connection and
result in a hung HTTP/1.0 proxy ...
... However, talking to proxies is the most important use of persistent
connections, so that prohibition is clearly unacceptable. Therefore,
we need some other mechanism for indicating a persistent connection
...
... connections, so that prohibition 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
...
... is desired, which is safe to use even when talking to an old proxy
that ignores Connection. Persistent connections are the default for
HTTP/1.1 ...
... proxy
that ignores Connection. Persistent connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection ...
... connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
declaring non-persistence.
...
... The following describes the original HTTP/1.0 form of persistent
connections.
When it connects to an origin server, an HTTP client ...
... HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
However, a persistent connection ...
...
When the Keep-Alive connection-token has been transmitted with a
request or a response, a Keep-Alive ...
... If the Keep-Alive header is sent, the corresponding connection token
MUST be transmitted. The Keep-Alive ...