Changeset 2032


Ignore:
Timestamp:
05/12/12 17:42:21 (9 years ago)
Author:
fielding@…
Message:

(editorial) improvements to persistent connections section; addresses #396

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2031 r2032  
    645645         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#connection.management">Connection Management</a><ul>
    646646               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    647                <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
    648                      <li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li>
    649                      <li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.reuse">Reuse</a><ul>
    650                            <li><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    651                            <li><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;&nbsp;&nbsp;<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>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li>
    655                      <li><a href="#rfc.section.6.2.4">6.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Time-outs</a></li>
    656                      <li><a href="#rfc.section.6.2.5">6.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li>
     647               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li>
     648               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a></li>
     649               <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.reuse">Reuse</a><ul>
     650                     <li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     651                     <li><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
    657652                  </ul>
    658653               </li>
    659                <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
     654               <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li>
     655               <li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Time-outs</a></li>
     656               <li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li>
     657               <li><a href="#rfc.section.6.8">6.8</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
    660658            </ul>
    661659         </li>
    … …  
    816814         phrase (<a href="#status.line" title="Status Line">Section&nbsp;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&nbsp;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&nbsp;3.3</a>).
    817815      </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="Persistent Connections">Section&nbsp;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&nbsp;6.3</a>.
    819817      </p>
    820818      <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>
    … …  
    14951493      <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
    14961494         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&nbsp;6.2.2.1</a>.
     1495         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.4.1</a>.
    14981496      </p>
    14991497      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    … …  
    18481846                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    18491847  <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&nbsp;6.3</a>
     1848                      ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.8</a>
    18511849  <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>
    18521850  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    … …  
    19781976      </p>
    19791977      <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&nbsp;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>&nbsp;<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>&nbsp;<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&nbsp;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>&nbsp;<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
    20151986         protocols. Each connection applies to only one transport link.
    20161987      </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>&nbsp;<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
    20181992         and <a href="#header.connection" class="smpl">Connection</a> header field (if any):
    20191993      </p>
    … …  
    20272001         <li>The connection will close after the current response.</li>
    20282002      </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>&nbsp;<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&nbsp;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&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    2039       </p>
    2040       <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;<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 to
     2003      <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&nbsp;3.3</a>.
     2006      </p>
     2007      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<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&nbsp;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>&nbsp;<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
    20462020         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.
    20472021      </p>
    2048       <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<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 recover
     2022      <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<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
    20502024         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
    20512025         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
    20522026         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.
    20532027      </p>
    2054       <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<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 many
     2028      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<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
    20582032         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    20592033         clients to be conservative when opening multiple connections.
    20602034      </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 significant
     2035      <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
    20622036         server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection
    20632037         consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks.
    20642038      </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       <h3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a>&nbsp;<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 servers
     2039      <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>&nbsp;<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
    20682042         might make this a higher value since it is likely that the client will be making more connections through the same server.
    20692043         The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
    20702044         or the server.
    20712045      </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 does
     2046      <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
    20732047         not detect the other side's close promptly it could cause unnecessary resource drain on the network.
    20742048      </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 time
     2049      <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
    20762050         that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
    20772051         while it was idle, but from the client's point of view, a request is in progress.
    20782052      </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,
    20802054         rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network
    20812055         congestion.
    20822056      </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 error
     2057      <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
    20842058         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection.
    20852059      </p>
    20862060      <div id="rfc.iref.c.13"></div>
    20872061      <div id="rfc.iref.c.14"></div>
    2088       <h3 id="rfc.section.6.2.5"><a href="#rfc.section.6.2.5">6.2.5</a>&nbsp;<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&nbsp;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>&nbsp;<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&nbsp;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;
    20982072         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.
    20992073      </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 able
     2074      <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
    21012075         to read the last HTTP response. If the server receives additional data from the client on a fully-closed connection, such
    21022076         as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a
    … …  
    21042078         can be read and interpreted by the client's HTTP parser.
    21052079      </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 the
     2080      <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
    21072081         read/write connection (a half-close) and continuing to read from the connection until the connection is closed by the client
    21082082         or the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing
    21092083         the server's last response. It is then safe for the server to fully close the connection.
    21102084      </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>
    21122086      <div id="rfc.iref.u.5"></div>
    2113       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<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 protocol
     2087      <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<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
    21152089         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
    21162090         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
    … …  
    21232097  <a href="#header.upgrade" class="smpl">protocol-name</a>    = <a href="#rule.token.separators" class="smpl">token</a>
    21242098  <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>
    21262100      <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 the
     2101</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
    21282102         more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available
    21292103         (where "better" is determined by the server, possibly according to the nature of the request method or target resource).
    21302104      </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 capabilities
     2105      <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
    21322106         and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol chosen,
    21332107         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.
    21342108      </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 target
     2109      <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
    21362110         resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of
    21372111         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
    21382112         by any protocol.
    21392113      </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&nbsp;6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
     2114      <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&nbsp;6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
    21412115         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.
    21422116      </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 used
     2117      <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
    21442118         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>).
    21452119      </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 defined
     2120      <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
    21472121         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    21482122         in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
    … …  
    22132187                  <td class="left">http</td>
    22142188                  <td class="left">standard</td>
    2215                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.3</a>
     2189                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.8</a>
    22162190                  </td>
    22172191               </tr>
    … …  
    29042878         in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;6.1</a>)
    29052879      </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="Persistent Connections">Section&nbsp;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="Persistent Connections">Section&nbsp;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&nbsp;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&nbsp;6.3</a>)
    29092883      </p>
    29102884      <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&nbsp;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="Persistent Connections">Section&nbsp;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&nbsp;6.3</a>)
     2885         (<a href="#persistent.reuse" title="Reuse">Section&nbsp;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&nbsp;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&nbsp;6.8</a>)
    29162890      </p>
    29172891      <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&nbsp;7.4</a>)
    … …  
    31123086                  <li>chunked (Coding Format)&nbsp;&nbsp;<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>
    31133087                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3114                   <li>close&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    31153089                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
    31163090                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3117                   <li>Connection header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    31183092                  <li>Content-Length header field&nbsp;&nbsp;<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>
    31193093               </ul>
    … …  
    32163190                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    32173191                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    3218                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.3</b></a></li>
     3192                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.8</b></a></li>
    32193193                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    32203194                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    … …  
    32713245            </li>
    32723246            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3273                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    32743248                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    32753249                        <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
    … …  
    32793253                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.7.2</a></li>
    32803254                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3281                         <li><em>Section 5.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.4.1</a>, <a href="#rfc.xref.Part2.28">6.4.2</a></li>
    32823256                        <li><em>Section 5.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.2</a></li>
    32833257                        <li><em>Section 5.3.6</em>&nbsp;&nbsp;<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>
    … …  
    32873261                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.6</a></li>
    32883262                        <li><em>Section 7.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3289                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.3</a></li>
     3263                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.8</a></li>
    32903264                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">8.6</a></li>
    32913265                        <li><em>Section 7.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">8.6</a></li>
    … …  
    33363310                  </li>
    33373311                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.4</a>, <a href="#RFC2047"><b>10.2</b></a></li>
    3338                   <li><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.3</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li>
    33403314                     </ul>
    33413315                  </li>
    … …  
    34103384            </li>
    34113385            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3412                   <li>Upgrade header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    34133387                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    34143388                  <li>URI scheme&nbsp;&nbsp;

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2031 r2032  
    27792779</t>
    27802780<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;
    27822782   send the "close" connection option in every request message.
    27832783</t>
    27842784<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;
    27862786   send the "close" connection option in every response message that
    27872787   does not have a <x:ref>1xx (Informational)</x:ref> status code.
    … …  
    27892789</section>
    27902790
    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 each
    2795    request/response pair. As the Web evolved and embedded requests became
    2796    common for inline images, the connection establishment overhead was
    2797    a significant drain on performance and a concern for Internet congestion.
    2798    Message framing (via <x:ref>Content-Length</x:ref>) and optional
    2799    long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order
    2800    to improve performance for some requests. However, these extensions were
    2801    insufficient for dynamically generated responses and difficult to use
    2802    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 single
    2807    connection. The "<x:ref>close</x:ref>" connection-option is used to
    2808    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 saved
    2813         in routers and hosts (clients, servers, proxies, gateways,
    2814         tunnels, or caches), and memory used for protocol control
    2815         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 without
    2820         waiting for each response, allowing a single connection to
    2821         be used much more efficiently and with less overall latency.
    2822       </t>
    2823       <t>
    2824         For TCP connections, network congestion is reduced by eliminating the
    2825         packets associated with the three way handshake and graceful close
    2826         procedures, and by allowing sufficient time to determine the
    2827         congestion state of the network.
    2828       </t>
    2829       <t>
    2830         Latency on subsequent requests is reduced since there is no time
    2831         spent in the connection opening handshake.
    2832       </t>
    2833       <t>
    2834         HTTP can evolve more gracefully, since most errors can be reported
    2835         without the penalty of closing the connection. Clients using
    2836         future versions of HTTP might optimistically try a new feature,
    2837         but if communicating with an older server, retry with old
    2838         semantics after an error is reported.
    2839       </t>
    2840     </list>
    2841 </t>
    2842 <t>
    2843    HTTP implementations &SHOULD; implement persistent connections.
    2844 </t>
    2845    
    28462791<section title="Establishment" anchor="persistent.establishment">
    28472792<t>
    … …  
    28492794   are established via various transport or session-layer protocols.
    28502795   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.
    28512807</t>
    28522808<t>
    … …  
    28722828   implemented by many HTTP/1.0 clients).
    28732829</t>
    2874 </section>
    2875 
    2876 <section title="Reuse" anchor="persistent.reuse">
    28772830<t>
    28782831   In order to remain persistent, all messages on a connection &MUST;
    … …  
    28802833   of the connection), as described in <xref target="message.body"/>.
    28812834</t>
     2835</section>
     2836
     2837<section title="Reuse" anchor="persistent.reuse">
    28822838<t>
    28832839   A server &MAY; assume that an HTTP/1.1 client intends to maintain a
    … …  
    30663022   be found in other transport connection protocols.
    30673023</t>
    3068 </section>
    30693024</section>
    30703025
Note: See TracChangeset for help on using the changeset viewer.