Changeset 2032
- Timestamp:
- 05/12/12 17:42:21 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2031 r2032 645 645 <li><a href="#rfc.section.6">6.</a> <a href="#connection.management">Connection Management</a><ul> 646 646 <li><a href="#rfc.section.6.1">6.1</a> <a href="#header.connection">Connection</a></li> 647 <li><a href="#rfc.section.6.2">6.2</a> <a href="#persistent.connections">Persistent Connections</a><ul> 648 <li><a href="#rfc.section.6.2.1">6.2.1</a> <a href="#persistent.establishment">Establishment</a></li> 649 <li><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#persistent.reuse">Reuse</a><ul> 650 <li><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a href="#pipelining">Pipelining</a></li> 651 <li><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 652 </ul> 653 </li> 654 <li><a href="#rfc.section.6.2.3">6.2.3</a> <a href="#persistent.concurrency">Concurrency</a></li> 655 <li><a href="#rfc.section.6.2.4">6.2.4</a> <a href="#persistent.failures">Failures and Time-outs</a></li> 656 <li><a href="#rfc.section.6.2.5">6.2.5</a> <a href="#persistent.tear-down">Tear-down</a></li> 647 <li><a href="#rfc.section.6.2">6.2</a> <a href="#persistent.establishment">Establishment</a></li> 648 <li><a href="#rfc.section.6.3">6.3</a> <a href="#persistent.connections">Persistence</a></li> 649 <li><a href="#rfc.section.6.4">6.4</a> <a href="#persistent.reuse">Reuse</a><ul> 650 <li><a href="#rfc.section.6.4.1">6.4.1</a> <a href="#pipelining">Pipelining</a></li> 651 <li><a href="#rfc.section.6.4.2">6.4.2</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 657 652 </ul> 658 653 </li> 659 <li><a href="#rfc.section.6.3">6.3</a> <a href="#header.upgrade">Upgrade</a></li> 654 <li><a href="#rfc.section.6.5">6.5</a> <a href="#persistent.concurrency">Concurrency</a></li> 655 <li><a href="#rfc.section.6.6">6.6</a> <a href="#persistent.failures">Failures and Time-outs</a></li> 656 <li><a href="#rfc.section.6.7">6.7</a> <a href="#persistent.tear-down">Tear-down</a></li> 657 <li><a href="#rfc.section.6.8">6.8</a> <a href="#header.upgrade">Upgrade</a></li> 660 658 </ul> 661 659 </li> … … 816 814 phrase (<a href="#status.line" title="Status Line">Section 3.1.2</a>), possibly followed by header fields containing server information, resource metadata, and representation metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 817 815 </p> 818 <p id="rfc.section.2.1.p.8">A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persisten t Connections">Section 6.2</a>.816 <p id="rfc.section.2.1.p.8">A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persistence">Section 6.3</a>. 819 817 </p> 820 818 <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> … … 1495 1493 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data 1496 1494 on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple 1497 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6. 2.2.1</a>.1495 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.4.1</a>. 1498 1496 </p> 1499 1497 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> … … 1848 1846 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1849 1847 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a> 1850 ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6. 3</a>1848 ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.8</a> 1851 1849 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 1852 1850 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1978 1976 </p> 1979 1977 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 1980 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.2.5</a>). 1981 </p> 1982 <p id="rfc.section.6.1.p.13">A client that does not support persistent connections <em class="bcp14">MUST</em> send the "close" connection option in every request message. 1983 </p> 1984 <p id="rfc.section.6.1.p.14">A server that does not support persistent connections <em class="bcp14">MUST</em> send the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code. 1985 </p> 1986 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> 1987 <p id="rfc.section.6.2.p.1">HTTP was originally designed to use a separate connection for each request/response pair. As the Web evolved and embedded 1988 requests became common for inline images, the connection establishment overhead was a significant drain on performance and 1989 a concern for Internet congestion. Message framing (via <a href="#header.content-length" class="smpl">Content-Length</a>) and optional long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order to improve performance for some requests. 1990 However, these extensions were insufficient for dynamically generated responses and difficult to use with intermediaries. 1991 </p> 1992 <p id="rfc.section.6.2.p.2">HTTP/1.1 defaults to the use of "<a href="#persistent.connections" class="smpl">persistent connections</a>", which allow multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will close after the current request/response. Persistent connections 1993 have a number of advantages: 1994 </p> 1995 <ul> 1996 <li>By opening and closing fewer connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, 1997 or caches), and memory used for protocol control blocks can be saved in hosts. 1998 </li> 1999 <li>Most requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without 2000 waiting for each response, allowing a single connection to be used much more efficiently and with less overall latency. 2001 </li> 2002 <li>For TCP connections, network congestion is reduced by eliminating the packets associated with the three way handshake and 2003 graceful close procedures, and by allowing sufficient time to determine the congestion state of the network. 2004 </li> 2005 <li>Latency on subsequent requests is reduced since there is no time spent in the connection opening handshake.</li> 2006 <li>HTTP can evolve more gracefully, since most errors can be reported without the penalty of closing the connection. Clients 2007 using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with 2008 old semantics after an error is reported. 2009 </li> 2010 </ul> 2011 <p id="rfc.section.6.2.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. 2012 </p> 2013 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="persistent.establishment" href="#persistent.establishment">Establishment</a></h3> 2014 <p id="rfc.section.6.2.1.p.1">It is beyond the scope of this specification to describe how connections are established via various transport or session-layer 1978 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.7</a>). 1979 </p> 1980 <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every request message. 1981 </p> 1982 <p id="rfc.section.6.1.p.14">A server that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code. 1983 </p> 1984 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="persistent.establishment" href="#persistent.establishment">Establishment</a></h2> 1985 <p id="rfc.section.6.2.p.1">It is beyond the scope of this specification to describe how connections are established via various transport or session-layer 2015 1986 protocols. Each connection applies to only one transport link. 2016 1987 </p> 2017 <p id="rfc.section.6.2.1.p.2">A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version 1988 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="persistent.connections" href="#persistent.connections">Persistence</a></h2> 1989 <p id="rfc.section.6.3.p.1">HTTP/1.1 defaults to the use of "<dfn>persistent connections</dfn>", which allow multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will not persist after the current request/response. HTTP implementations <em class="bcp14">SHOULD</em> support persistent connections. 1990 </p> 1991 <p id="rfc.section.6.3.p.2">A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version 2018 1992 and <a href="#header.connection" class="smpl">Connection</a> header field (if any): 2019 1993 </p> … … 2027 2001 <li>The connection will close after the current response.</li> 2028 2002 </ul> 2029 <p id="rfc.section.6. 2.1.p.3">A proxy server <em class="bcp14">MUST NOT</em> maintain a persistent connection with an HTTP/1.0 client (see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).2030 </p> 2031 < h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.reuse" href="#persistent.reuse">Reuse</a></h3>2032 < p id="rfc.section.6.2.2.p.1">In order to remain persistent, all messages on a connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>.2033 < /p>2034 <p id="rfc.section.6. 2.2.p.2">A server <em class="bcp14">MAY</em> assume that an HTTP/1.1 client intends to maintain a persistent connection until a <a href="#header.connection" class="smpl">close</a> connection option is received in a request.2035 </p> 2036 <p id="rfc.section.6. 2.2.p.3">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option.2037 </p> 2038 <p id="rfc.section.6. 2.2.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.2039 </p> 2040 <h 4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4>2041 <p id="rfc.section.6. 2.2.1.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.2042 </p> 2043 <p id="rfc.section.6. 2.2.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.2044 </p> 2045 <p id="rfc.section.6. 2.2.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2003 <p id="rfc.section.6.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> maintain a persistent connection with an HTTP/1.0 client (see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 2004 </p> 2005 <p id="rfc.section.6.3.p.4">In order to remain persistent, all messages on a connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 2006 </p> 2007 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="persistent.reuse" href="#persistent.reuse">Reuse</a></h2> 2008 <p id="rfc.section.6.4.p.1">A server <em class="bcp14">MAY</em> assume that an HTTP/1.1 client intends to maintain a persistent connection until a <a href="#header.connection" class="smpl">close</a> connection option is received in a request. 2009 </p> 2010 <p id="rfc.section.6.4.p.2">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option. 2011 </p> 2012 <p id="rfc.section.6.4.p.3">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 2013 </p> 2014 <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <a id="pipelining" href="#pipelining">Pipelining</a></h3> 2015 <p id="rfc.section.6.4.1.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received. 2016 </p> 2017 <p id="rfc.section.6.4.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2018 </p> 2019 <p id="rfc.section.6.4.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2046 2020 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2047 2021 </p> 2048 <h 4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4>2049 <p id="rfc.section.6. 2.2.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover2022 <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2023 <p id="rfc.section.6.4.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover 2050 2024 from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence 2051 2025 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding 2052 2026 of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails. 2053 2027 </p> 2054 <h 3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h3>2055 <p id="rfc.section.6. 2.3.p.1">Clients <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server.2056 </p> 2057 <p id="rfc.section.6. 2.3.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many2028 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h2> 2029 <p id="rfc.section.6.5.p.1">Clients <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server. 2030 </p> 2031 <p id="rfc.section.6.5.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many 2058 2032 applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages 2059 2033 clients to be conservative when opening multiple connections. 2060 2034 </p> 2061 <p id="rfc.section.6. 2.3.p.3">Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant2035 <p id="rfc.section.6.5.p.3">Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant 2062 2036 server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection 2063 2037 consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks. 2064 2038 </p> 2065 <p id="rfc.section.6. 2.3.p.4">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>2066 <h 3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a> <a id="persistent.failures" href="#persistent.failures">Failures and Time-outs</a></h3>2067 <p id="rfc.section.6. 2.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers2039 <p id="rfc.section.6.5.p.4">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> 2040 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="persistent.failures" href="#persistent.failures">Failures and Time-outs</a></h2> 2041 <p id="rfc.section.6.6.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers 2068 2042 might make this a higher value since it is likely that the client will be making more connections through the same server. 2069 2043 The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client 2070 2044 or the server. 2071 2045 </p> 2072 <p id="rfc.section.6. 2.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does2046 <p id="rfc.section.6.6.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does 2073 2047 not detect the other side's close promptly it could cause unnecessary resource drain on the network. 2074 2048 </p> 2075 <p id="rfc.section.6. 2.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time2049 <p id="rfc.section.6.6.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time 2076 2050 that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed 2077 2051 while it was idle, but from the client's point of view, a request is in progress. 2078 2052 </p> 2079 <p id="rfc.section.6. 2.4.p.4">Servers <em class="bcp14">SHOULD</em> maintain persistent connections and allow the underlying transport's flow control mechanisms to resolve temporary overloads,2053 <p id="rfc.section.6.6.p.4">Servers <em class="bcp14">SHOULD</em> maintain persistent connections and allow the underlying transport's flow control mechanisms to resolve temporary overloads, 2080 2054 rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network 2081 2055 congestion. 2082 2056 </p> 2083 <p id="rfc.section.6. 2.4.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error2057 <p id="rfc.section.6.6.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 2084 2058 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection. 2085 2059 </p> 2086 2060 <div id="rfc.iref.c.13"></div> 2087 2061 <div id="rfc.iref.c.14"></div> 2088 <h 3 id="rfc.section.6.2.5"><a href="#rfc.section.6.2.5">6.2.5</a> <a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h3>2089 <p id="rfc.section.6. 2.5.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.2090 </p> 2091 <p id="rfc.section.6. 2.5.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request.2092 </p> 2093 <p id="rfc.section.6. 2.5.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2094 </p> 2095 <p id="rfc.section.6. 2.5.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2096 </p> 2097 <p id="rfc.section.6. 2.5.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close;2062 <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h2> 2063 <p id="rfc.section.6.7.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair. 2064 </p> 2065 <p id="rfc.section.6.7.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. 2066 </p> 2067 <p id="rfc.section.6.7.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2068 </p> 2069 <p id="rfc.section.6.7.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2070 </p> 2071 <p id="rfc.section.6.7.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close; 2098 2072 if additional pipelined requests had been sent on the connection, the client <em class="bcp14">SHOULD</em> assume that they will not be processed by the server. 2099 2073 </p> 2100 <p id="rfc.section.6. 2.5.p.6">If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able2074 <p id="rfc.section.6.7.p.6">If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able 2101 2075 to read the last HTTP response. If the server receives additional data from the client on a fully-closed connection, such 2102 2076 as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a … … 2104 2078 can be read and interpreted by the client's HTTP parser. 2105 2079 </p> 2106 <p id="rfc.section.6. 2.5.p.7">To avoid the TCP reset problem, a server can perform a lingering close on a connection by closing only the write side of the2080 <p id="rfc.section.6.7.p.7">To avoid the TCP reset problem, a server can perform a lingering close on a connection by closing only the write side of the 2107 2081 read/write connection (a half-close) and continuing to read from the connection until the connection is closed by the client 2108 2082 or the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing 2109 2083 the server's last response. It is then safe for the server to fully close the connection. 2110 2084 </p> 2111 <p id="rfc.section.6. 2.5.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p>2085 <p id="rfc.section.6.7.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p> 2112 2086 <div id="rfc.iref.u.5"></div> 2113 <h2 id="rfc.section.6. 3"><a href="#rfc.section.6.3">6.3</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>2114 <p id="rfc.section.6. 3.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol2087 <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2088 <p id="rfc.section.6.8.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol 2115 2089 on the same connection. A client <em class="bcp14">MAY</em> send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols 2116 2090 before sending the final response. A server <em class="bcp14">MUST</em> send an Upgrade header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching … … 2123 2097 <a href="#header.upgrade" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2124 2098 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2125 </pre><p id="rfc.section.6. 3.p.3">For example,</p>2099 </pre><p id="rfc.section.6.8.p.3">For example,</p> 2126 2100 <div id="rfc.figure.u.58"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2127 </pre><p id="rfc.section.6. 3.p.5">Upgrade eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the2101 </pre><p id="rfc.section.6.8.p.5">Upgrade eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the 2128 2102 more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available 2129 2103 (where "better" is determined by the server, possibly according to the nature of the request method or target resource). 2130 2104 </p> 2131 <p id="rfc.section.6. 3.p.6">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities2105 <p id="rfc.section.6.8.p.6">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2132 2106 and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol chosen, 2133 2107 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field. 2134 2108 </p> 2135 <p id="rfc.section.6. 3.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it <em class="bcp14">MUST</em> first respond with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follow that with the new protocol's equivalent of a response to a GET on the target2109 <p id="rfc.section.6.8.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it <em class="bcp14">MUST</em> first respond with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follow that with the new protocol's equivalent of a response to a GET on the target 2136 2110 resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of 2137 2111 an additional round-trip. A server <em class="bcp14">MUST NOT</em> switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored 2138 2112 by any protocol. 2139 2113 </p> 2140 <p id="rfc.section.6. 3.p.8">When Upgrade is sent, a sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries2114 <p id="rfc.section.6.8.p.8">When Upgrade is sent, a sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries 2141 2115 that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request. 2142 2116 </p> 2143 <p id="rfc.section.6. 3.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used2117 <p id="rfc.section.6.8.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used 2144 2118 to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2145 2119 </p> 2146 <p id="rfc.section.6. 3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2120 <p id="rfc.section.6.8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2147 2121 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2148 2122 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. … … 2213 2187 <td class="left">http</td> 2214 2188 <td class="left">standard</td> 2215 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6. 3</a>2189 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.8</a> 2216 2190 </td> 2217 2191 </tr> … … 2904 2878 in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 6.1</a>) 2905 2879 </p> 2906 <p id="rfc.section.A.2.p.28">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persisten t Connections">Section 6.2</a>)2907 </p> 2908 <p id="rfc.section.A.2.p.29">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persisten t Connections">Section 6.2</a>)2880 <p id="rfc.section.A.2.p.28">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2881 </p> 2882 <p id="rfc.section.A.2.p.29">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2909 2883 </p> 2910 2884 <p id="rfc.section.A.2.p.30">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. 2911 (<a href="#persistent.reuse" title="Reuse">Section 6. 2.2</a>)2912 </p> 2913 <p id="rfc.section.A.2.p.31">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persisten t Connections">Section 6.2</a>)2914 </p> 2915 <p id="rfc.section.A.2.p.32">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6. 3</a>)2885 (<a href="#persistent.reuse" title="Reuse">Section 6.4</a>) 2886 </p> 2887 <p id="rfc.section.A.2.p.31">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2888 </p> 2889 <p id="rfc.section.A.2.p.32">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.8</a>) 2916 2890 </p> 2917 2891 <p id="rfc.section.A.2.p.33">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>) … … 3112 3086 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li> 3113 3087 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3114 <li>close <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6. 2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3088 <li>close <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.7</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">6.8</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3115 3089 <li>compress (Coding Format) <a href="#rfc.iref.c.10">4.2.1</a></li> 3116 3090 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3117 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6. 2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3091 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.7</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">6.8</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3118 3092 <li>Content-Length header field <a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li> 3119 3093 </ul> … … 3216 3190 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3217 3191 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3218 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6. 3</b></a></li>3192 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.8</b></a></li> 3219 3193 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3220 3194 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> … … 3271 3245 </li> 3272 3246 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3273 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.6</a>, <a href="#rfc.xref.Part2.21">5.7.2</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6. 2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3247 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.6</a>, <a href="#rfc.xref.Part2.21">5.7.2</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6.4.1</a>, <a href="#rfc.xref.Part2.28">6.4.2</a>, <a href="#rfc.xref.Part2.29">6.8</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3274 3248 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3275 3249 <li><em>Section 3.1.1.5</em> <a href="#rfc.xref.Part2.26">5.7.2</a></li> … … 3279 3253 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.21">5.7.2</a></li> 3280 3254 <li><em>Section 5</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3281 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.27">6. 2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a></li>3255 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.27">6.4.1</a>, <a href="#rfc.xref.Part2.28">6.4.2</a></li> 3282 3256 <li><em>Section 5.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.2</a></li> 3283 3257 <li><em>Section 5.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.18">5.3</a></li> … … 3287 3261 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.20">5.6</a></li> 3288 3262 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3289 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.29">6. 3</a></li>3263 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.29">6.8</a></li> 3290 3264 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2.32">8.6</a></li> 3291 3265 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">8.6</a></li> … … 3336 3310 </li> 3337 3311 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.4</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3338 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6. 2.1</a>, <a href="#rfc.xref.RFC2068.4">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul>3339 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6. 2.1</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li>3312 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.3</a>, <a href="#rfc.xref.RFC2068.4">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul> 3313 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.3</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li> 3340 3314 </ul> 3341 3315 </li> … … 3410 3384 </li> 3411 3385 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3412 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">5.7.1</a>, <a href="#rfc.iref.u.5"><b>6. 3</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3386 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">5.7.1</a>, <a href="#rfc.iref.u.5"><b>6.8</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3413 3387 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3414 3388 <li>URI scheme -
draft-ietf-httpbis/latest/p1-messaging.xml
r2031 r2032 2779 2779 </t> 2780 2780 <t> 2781 A client that does not support persistent connections&MUST;2781 A client that does not support <x:ref>persistent connections</x:ref> &MUST; 2782 2782 send the "close" connection option in every request message. 2783 2783 </t> 2784 2784 <t> 2785 A server that does not support persistent connections&MUST;2785 A server that does not support <x:ref>persistent connections</x:ref> &MUST; 2786 2786 send the "close" connection option in every response message that 2787 2787 does not have a <x:ref>1xx (Informational)</x:ref> status code. … … 2789 2789 </section> 2790 2790 2791 <section title="Persistent Connections" anchor="persistent.connections">2792 <x:anchor-alias value="persistent connections"/>2793 <t>2794 HTTP was originally designed to use a separate connection for each2795 request/response pair. As the Web evolved and embedded requests became2796 common for inline images, the connection establishment overhead was2797 a significant drain on performance and a concern for Internet congestion.2798 Message framing (via <x:ref>Content-Length</x:ref>) and optional2799 long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order2800 to improve performance for some requests. However, these extensions were2801 insufficient for dynamically generated responses and difficult to use2802 with intermediaries.2803 </t>2804 <t>2805 HTTP/1.1 defaults to the use of "<x:ref>persistent connections</x:ref>",2806 which allow multiple requests and responses to be carried over a single2807 connection. The "<x:ref>close</x:ref>" connection-option is used to2808 signal that a connection will close after the current request/response.2809 Persistent connections have a number of advantages:2810 <list style="symbols">2811 <t>2812 By opening and closing fewer connections, CPU time is saved2813 in routers and hosts (clients, servers, proxies, gateways,2814 tunnels, or caches), and memory used for protocol control2815 blocks can be saved in hosts.2816 </t>2817 <t>2818 Most requests and responses can be pipelined on a connection.2819 Pipelining allows a client to make multiple requests without2820 waiting for each response, allowing a single connection to2821 be used much more efficiently and with less overall latency.2822 </t>2823 <t>2824 For TCP connections, network congestion is reduced by eliminating the2825 packets associated with the three way handshake and graceful close2826 procedures, and by allowing sufficient time to determine the2827 congestion state of the network.2828 </t>2829 <t>2830 Latency on subsequent requests is reduced since there is no time2831 spent in the connection opening handshake.2832 </t>2833 <t>2834 HTTP can evolve more gracefully, since most errors can be reported2835 without the penalty of closing the connection. Clients using2836 future versions of HTTP might optimistically try a new feature,2837 but if communicating with an older server, retry with old2838 semantics after an error is reported.2839 </t>2840 </list>2841 </t>2842 <t>2843 HTTP implementations &SHOULD; implement persistent connections.2844 </t>2845 2846 2791 <section title="Establishment" anchor="persistent.establishment"> 2847 2792 <t> … … 2849 2794 are established via various transport or session-layer protocols. 2850 2795 Each connection applies to only one transport link. 2796 </t> 2797 </section> 2798 2799 <section title="Persistence" anchor="persistent.connections"> 2800 <x:anchor-alias value="persistent connections"/> 2801 <t> 2802 HTTP/1.1 defaults to the use of "<x:dfn>persistent connections</x:dfn>", 2803 which allow multiple requests and responses to be carried over a single 2804 connection. The "<x:ref>close</x:ref>" connection-option is used to signal 2805 that a connection will not persist after the current request/response. 2806 HTTP implementations &SHOULD; support persistent connections. 2851 2807 </t> 2852 2808 <t> … … 2872 2828 implemented by many HTTP/1.0 clients). 2873 2829 </t> 2874 </section>2875 2876 <section title="Reuse" anchor="persistent.reuse">2877 2830 <t> 2878 2831 In order to remain persistent, all messages on a connection &MUST; … … 2880 2833 of the connection), as described in <xref target="message.body"/>. 2881 2834 </t> 2835 </section> 2836 2837 <section title="Reuse" anchor="persistent.reuse"> 2882 2838 <t> 2883 2839 A server &MAY; assume that an HTTP/1.1 client intends to maintain a … … 3066 3022 be found in other transport connection protocols. 3067 3023 </t> 3068 </section>3069 3024 </section> 3070 3025
Note: See TracChangeset
for help on using the changeset viewer.