Changeset 1838 for draft-ietf-httpbis


Ignore:
Timestamp:
20/08/12 08:33:10 (9 years ago)
Author:
fielding@…
Message:

reorganize the persistent connection requirements into sections that correspond to implementation states

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

Legend:

Unmodified
Added
Removed

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

    r1837 r1838  
    449449  }
    450450  @bottom-center {
    451        content: "Expires February 20, 2013";
     451       content: "Expires February 21, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-08-19">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-08-20">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: February 20, 2013</td>
     526               <td class="left">Expires: February 21, 2013</td>
    527527               <td class="right">greenbytes</td>
    528528            </tr>
    529529            <tr>
    530530               <td class="left"></td>
    531                <td class="right">August 19, 2012</td>
     531               <td class="right">August 20, 2012</td>
    532532            </tr>
    533533         </tbody>
    … …  
    556556         in progress”.
    557557      </p>
    558       <p>This Internet-Draft will expire on February 20, 2013.</p>
     558      <p>This Internet-Draft will expire on February 21, 2013.</p>
    559559      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    560560      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    647647               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    648648               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
    649                      <li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
    650                            <li><a href="#rfc.section.6.2.1.1">6.2.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
    651                            <li><a href="#rfc.section.6.2.1.2">6.2.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     649                     <li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li>
     650                     <li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.reuse">Reuse</a><ul>
     651                           <li><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     652                           <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>
    652653                        </ul>
    653654                     </li>
    654                      <li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
    655                      <li><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
     655                     <li><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li>
     656                     <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>
     657                     <li><a href="#rfc.section.6.2.5">6.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li>
    656658                  </ul>
    657659               </li>
    658                <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>
    659                      <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
    660                      <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
    661                      <li><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
    662                      <li><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#closing.connections.on.error">Closing Connections on Error</a></li>
    663                   </ul>
    664                </li>
     660               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
    665661               <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
    666662            </ul>
    … …  
    15061502      <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
    15071503         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
    1508          requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.2.1.2</a>.
     1504         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.2.2.1</a>.
    15091505      </p>
    15101506      <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>
    … …  
    19841980         connection option, since it would be unwise for senders to use that field-name for anything else.
    19851981      </p>
    1986       <p id="rfc.section.6.1.p.10">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
    1987          of the response. For example,
     1982      <p id="rfc.section.6.1.p.10">HTTP/1.1 defines the "<dfn>close</dfn>" connection option for the sender to signal that this connection will be closed after completion of the response. For example,
    19881983      </p>
    19891984      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
    … …  
    20001995         However, these extensions were insufficient for dynamically generated responses and difficult to use with intermediaries.
    20011996      </p>
    2002       <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. Persistent connections have a number
    2003          of advantages:
     1997      <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
     1998         have a number of advantages:
    20041999      </p>
    20052000      <ul>
    … …  
    20212016      <p id="rfc.section.6.2.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
    20222017      </p>
    2023       <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
    2024       <p id="rfc.section.6.2.1.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
    2025          of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server.
    2026       </p>
    2027       <p id="rfc.section.6.2.1.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
    2028          takes place using 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>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    2029       </p>
    2030       <h4 id="rfc.section.6.2.1.1"><a href="#rfc.section.6.2.1.1">6.2.1.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    2031       <p id="rfc.section.6.2.1.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection
    2032          immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
    2033       </p>
    2034       <p id="rfc.section.6.2.1.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
    2035          a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that
    2036          request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
    2037       </p>
    2038       <p id="rfc.section.6.2.1.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection.
    2039       </p>
    2040       <p id="rfc.section.6.2.1.1.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.
    2041       </p>
    2042       <p id="rfc.section.6.2.1.1.p.5">Each persistent connection applies to only one transport link.</p>
    2043       <p id="rfc.section.6.2.1.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but 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).
    2044       </p>
    2045       <p id="rfc.section.6.2.1.1.p.7">In order to remain persistent, all messages on the 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>.
    2046       </p>
    2047       <h4 id="rfc.section.6.2.1.2"><a href="#rfc.section.6.2.1.2">6.2.1.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
    2048       <p id="rfc.section.6.2.1.2.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.
    2049       </p>
    2050       <p id="rfc.section.6.2.1.2.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.
    2051       </p>
    2052       <p id="rfc.section.6.2.1.2.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 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2018      <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>
     2019      <p id="rfc.section.6.2.1.p.1">Each connection applies to only one transport link.</p>
     2020      <p id="rfc.section.6.2.1.p.2">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request.
     2021      </p>
     2022      <p id="rfc.section.6.2.1.p.3">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
     2023         a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close".
     2024      </p>
     2025      <p id="rfc.section.6.2.1.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.
     2026      </p>
     2027      <p id="rfc.section.6.2.1.p.5">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but 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).
     2028      </p>
     2029      <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>
     2030      <p id="rfc.section.6.2.2.p.1">Unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server.
     2031      </p>
     2032      <p id="rfc.section.6.2.2.p.2">In order to remain persistent, all messages on the 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      <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>
     2035      <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.
     2036      </p>
     2037      <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.
     2038      </p>
     2039      <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 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    20532040         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.
    20542041      </p>
    2055       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    2056       <p id="rfc.section.6.2.2.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
     2042      <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>
     2043      <p id="rfc.section.6.2.2.2.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
     2044         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, 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
     2045         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
     2046      </p>
     2047      <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>
     2048      <p id="rfc.section.6.2.3.p.1">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
     2049      </p>
     2050      <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
     2051         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
     2052         clients to be conservative when opening multiple connections.
     2053      </p>
     2054      <p id="rfc.section.6.2.3.p.3">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
     2055         server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
     2056         consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
     2057         effects in congested networks.
     2058      </p>
     2059      <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>
     2060      <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>
     2061      <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
    20572062         might make this a higher value since it is likely that the client will be making more connections through the same server.
    20582063         The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
    20592064         or the server.
    20602065      </p>
    2061       <p id="rfc.section.6.2.2.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
     2066      <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
    20622067         not detect the other side's close promptly it could cause unnecessary resource drain on the network.
    20632068      </p>
    2064       <p id="rfc.section.6.2.2.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
     2069      <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
    20652070         that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
    20662071         while it was idle, but from the client's point of view, a request is in progress.
    20672072      </p>
    2068       <p id="rfc.section.6.2.2.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
    2069       </p>
    2070       <p id="rfc.section.6.2.2.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
    2071          applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    2072          clients to be conservative when opening multiple connections.
    2073       </p>
    2074       <p id="rfc.section.6.2.2.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
    2075          server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
    2076          consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
    2077          effects in congested networks.
    2078       </p>
    2079       <p id="rfc.section.6.2.2.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
    2080       <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    2081       <p id="rfc.section.6.2.3.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2082          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, 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
    2083          of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    2084       </p>
    2085       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
    2086       <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
    2087       <p id="rfc.section.6.3.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
     2073      <p id="rfc.section.6.2.4.p.4">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
    20882074         connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.
    20892075      </p>
    2090       <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    2091       <p id="rfc.section.6.3.2.p.1">An HTTP/1.1 (or later) 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
    2092          status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    2093       </p>
    2094       <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2095       <p id="rfc.section.6.3.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2076      <p id="rfc.section.6.2.4.p.5">An HTTP/1.1 (or later) 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
     2077         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection.
     2078      </p>
     2079      <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>
     2080      <p id="rfc.section.6.2.5.p.1">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
     2081         takes place using 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>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
     2082      </p>
     2083      <p id="rfc.section.6.2.5.p.2">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request/response pair becomes the last one for the connection.
     2084      </p>
     2085      <p id="rfc.section.6.2.5.p.3">If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
     2086      </p>
     2087      <p id="rfc.section.6.2.5.p.4">In case the client does not want to maintain a connection for more than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
     2088      </p>
     2089      <p id="rfc.section.6.2.5.p.5">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
     2090         the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send
     2091         a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted
     2092         by the HTTP application.
     2093      </p>
     2094      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h2>
     2095      <p id="rfc.section.6.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    20962096         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    20972097         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    20982098         looking at the body.
    20992099      </p>
    2100       <p id="rfc.section.6.3.3.p.2">Requirements for HTTP/1.1 clients: </p>
     2100      <p id="rfc.section.6.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21012101      <ul>
    21022102         <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) with the "100-continue" expectation.
    … …  
    21052105         </li>
    21062106      </ul>
    2107       <p id="rfc.section.6.3.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
     2107      <p id="rfc.section.6.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    21082108         100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has
    21092109         never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    21102110      </p>
    2111       <p id="rfc.section.6.3.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
     2111      <p id="rfc.section.6.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    21122112      <ul>
    21132113         <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    … …  
    21292129         </li>
    21302130      </ul>
    2131       <p id="rfc.section.6.3.3.p.5">Requirements for HTTP/1.1 proxies: </p>
     2131      <p id="rfc.section.6.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    21322132      <ul>
    21332133         <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1
    … …  
    21412141         </li>
    21422142      </ul>
    2143       <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3>
    2144       <p id="rfc.section.6.3.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
    2145          the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send
    2146          a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted
    2147          by the HTTP application.
    2148       </p>
    21492143      <div id="rfc.iref.u.5"></div>
    21502144      <div id="rfc.iref.h.14"></div>
    … …  
    29062900      </p>
    29072901      <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent.
    2908          Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.2.2</a>)
    2909       </p>
    2910       <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain circumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section&nbsp;6.3</a>)
     2902         Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.2</a>)
     2903      </p>
     2904      <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain circumstances when the server prematurely closes the connection. (<a href="#persistent.reuse" title="Reuse">Section&nbsp;6.2.2</a>)
    29112905      </p>
    29122906      <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value.</p>
    … …  
    35023496                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    35033497                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3504                   <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</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.1</a>, <a href="#rfc.xref.header.connection.7">6.4</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></li>
     3498                  <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</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.4</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></li>
    35053499                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li>
    35063500               </ul>
    … …  
    36193613                  <li>Header Fields&nbsp;&nbsp;
    36203614                     <ul>
    3621                         <li>Connection&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</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.1</a>, <a href="#rfc.xref.header.connection.7">6.4</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></li>
     3615                        <li>Connection&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</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.4</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></li>
    36223616                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li>
    36233617                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>
    … …  
    36703664            </li>
    36713665            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3672                   <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.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.1.2</a>, <a href="#rfc.xref.Part2.23">6.2.3</a>, <a href="#rfc.xref.Part2.24">6.3.3</a>, <a href="#rfc.xref.Part2.25">6.3.3</a>, <a href="#rfc.xref.Part2.26">6.3.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3666                  <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.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a>, <a href="#rfc.xref.Part2.24">6.3</a>, <a href="#rfc.xref.Part2.25">6.3</a>, <a href="#rfc.xref.Part2.26">6.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    36733667                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a></li>
    3674                         <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.2.1.2</a>, <a href="#rfc.xref.Part2.23">6.2.3</a></li>
     3668                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a></li>
    36753669                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
    36763670                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    36773671                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    36783672                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li>
    3679                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.26">6.3.3</a></li>
    3680                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3.3</a></li>
     3673                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.26">6.3</a></li>
     3674                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3</a></li>
    36813675                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    36823676                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.4</a></li>
    … …  
    36903684                        <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
    36913685                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3692                         <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.3.3</a></li>
     3686                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.3</a></li>
    36933687                        <li><em>Section 9.17</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.8</a></li>
    36943688                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    … …  
    37343728                  </li>
    37353729                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li>
    3736                   <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.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>
    3737                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.2.1.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>
     3730                  <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">6.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>
     3731                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>
    37383732                     </ul>
    37393733                  </li>

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

    r1837 r1838  
    26822682  <x:anchor-alias value="Connection"/>
    26832683  <x:anchor-alias value="connection-option"/>
     2684  <x:anchor-alias value="close"/>
    26842685<t>
    26852686   The "Connection" header field allows the sender to indicate desired
    … …  
    27482749</t>
    27492750<t>
    2750    HTTP/1.1 defines the "close" connection option for the sender to
    2751    signal that the connection will be closed after completion of the
    2752    response. For example,
     2751   HTTP/1.1 defines the "<x:dfn>close</x:dfn>" connection option for the
     2752   sender to signal that this connection will be closed after completion of
     2753   the response. For example,
    27532754</t>
    27542755<figure><artwork type="example">
    … …  
    27872788   HTTP/1.1 defaults to the use of "<x:ref>persistent connections</x:ref>",
    27882789   which allow multiple requests and responses to be carried over a single
    2789    connection.
     2790   connection. The "<x:ref>close</x:ref>" connection-option is used to
     2791   signal that a connection will close after the current request/response.
    27902792   Persistent connections have a number of advantages:
    27912793  <list style="symbols">
    … …  
    28242826   HTTP implementations &SHOULD; implement persistent connections.
    28252827</t>
    2826 
    2827 <section title="Overall Operation" anchor="persistent.overall">
    2828 <t>
    2829    A significant difference between HTTP/1.1 and earlier versions of
    2830    HTTP is that persistent connections are the default behavior of any
    2831    HTTP connection. That is, unless otherwise indicated, the client
    2832    &SHOULD; assume that the server will maintain a persistent connection,
    2833    even after error responses from the server.
    2834 </t>
    2835 <t>
    2836    Persistent connections provide a mechanism by which a client and a
    2837    server can signal the close of a TCP connection. This signaling takes
    2838    place using the <x:ref>Connection</x:ref> header field
    2839    (<xref target="header.connection"/>). Once a close has been signaled, the
    2840    client &MUST-NOT; send any more requests on that
    2841    connection.
    2842 </t>
    2843 
    2844 <section title="Negotiation" anchor="persistent.negotiation">
     2828   
     2829<section title="Establishment" anchor="persistent.establishment">
     2830<t>
     2831   Each connection applies to only one transport link.
     2832</t>
    28452833<t>
    28462834   An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
    28472835   maintain a persistent connection unless a <x:ref>Connection</x:ref> header
    2848    field including the connection option "close" was sent in the request. If
    2849    the server chooses to close the connection immediately after sending the
    2850    response, it &SHOULD; send a Connection header field including the
    2851    connection option "close".
     2836   field including the connection option "close" was sent in the request.
    28522837</t>
    28532838<t>
    … …  
    28552840   decide to keep it open based on whether the response from a server
    28562841   contains a <x:ref>Connection</x:ref> header field with the connection option
    2857    "close". In case the client does not want to maintain a connection for more
    2858    than that request, it &SHOULD; send a Connection header field including the
    2859    connection option "close".
    2860 </t>
    2861 <t>
    2862    If either the client or the server sends the "close" option in the
    2863    <x:ref>Connection</x:ref> header field, that request becomes the last one
    2864    for the connection.
     2842   "close".
    28652843</t>
    28662844<t>
    … …  
    28712849</t>
    28722850<t>
    2873    Each persistent connection applies to only one transport link.
    2874 </t>
    2875 <t>
    28762851   A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
    28772852   with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
    … …  
    28792854   implemented by many HTTP/1.0 clients).
    28802855</t>
     2856</section>
     2857
     2858<section title="Reuse" anchor="persistent.reuse">
     2859<t>
     2860   Unless otherwise indicated, the client
     2861   &SHOULD; assume that the server will maintain a persistent connection,
     2862   even after error responses from the server.
     2863</t>
    28812864<t>
    28822865   In order to remain persistent, all messages on the connection &MUST;
    … …  
    28842867   of the connection), as described in <xref target="message.body"/>.
    28852868</t>
    2886 </section>
    28872869
    28882870<section title="Pipelining" anchor="pipelining">
    … …  
    29032885</t>
    29042886<t>
    2905    Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods or
    2906    non-idempotent sequences of request methods (see &idempotent-methods;). Otherwise, a
    2907    premature termination of the transport connection could lead to
    2908    indeterminate results. A client wishing to send a non-idempotent
     2887   Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods
     2888   or non-idempotent sequences of request methods (see &idempotent-methods;).
     2889   Otherwise, a premature termination of the transport connection could lead
     2890   to indeterminate results. A client wishing to send a non-idempotent
    29092891   request &SHOULD; wait to send that request until it has received the
    29102892   response status line for the previous request.
    2911 </t>
    2912 </section>
    2913 </section>
    2914 
    2915 <section title="Practical Considerations" anchor="persistent.practical">
    2916 <t>
    2917    Servers will usually have some time-out value beyond which they will
    2918    no longer maintain an inactive connection. Proxy servers might make
    2919    this a higher value since it is likely that the client will be making
    2920    more connections through the same server. The use of persistent
    2921    connections places no requirements on the length (or existence) of
    2922    this time-out for either the client or the server.
    2923 </t>
    2924 <t>
    2925    When a client or server wishes to time-out it &SHOULD; issue a graceful
    2926    close on the transport connection. Clients and servers &SHOULD; both
    2927    constantly watch for the other side of the transport close, and
    2928    respond to it as appropriate. If a client or server does not detect
    2929    the other side's close promptly it could cause unnecessary resource
    2930    drain on the network.
    2931 </t>
    2932 <t>
    2933    A client, server, or proxy &MAY; close the transport connection at any
    2934    time. For example, a client might have started to send a new request
    2935    at the same time that the server has decided to close the "idle"
    2936    connection. From the server's point of view, the connection is being
    2937    closed while it was idle, but from the client's point of view, a
    2938    request is in progress.
    2939 </t>
    2940 <t>
    2941    Clients (including proxies) &SHOULD; limit the number of simultaneous
    2942    connections that they maintain to a given server (including proxies).
    2943 </t>
    2944 <t>
    2945    Previous revisions of HTTP gave a specific number of connections as a
    2946    ceiling, but this was found to be impractical for many applications. As a
    2947    result, this specification does not mandate a particular maximum number of
    2948    connections, but instead encourages clients to be conservative when opening
    2949    multiple connections.
    2950 </t>
    2951 <t>
    2952    In particular, while using multiple connections avoids the "head-of-line
    2953    blocking" problem (whereby a request that takes significant server-side
    2954    processing and/or has a large payload can block subsequent requests on the
    2955    same connection), each connection used consumes server resources (sometimes
    2956    significantly), and furthermore using multiple connections can cause
    2957    undesirable side effects in congested networks.
    2958 </t>
    2959 <t>
    2960    Note that servers might reject traffic that they deem abusive, including an
    2961    excessive number of connections from a client.
    29622893</t>
    29632894</section>
    … …  
    29792910</section>
    29802911</section>
    2981 
    2982 <section title="Message Transmission Requirements" anchor="message.transmission.requirements">
    2983 
    2984 <section title="Persistent Connections and Flow Control" anchor="persistent.flow">
     2912   
     2913<section title="Concurrency" anchor="persistent.concurrency">
     2914<t>
     2915   Clients (including proxies) &SHOULD; limit the number of simultaneous
     2916   connections that they maintain to a given server (including proxies).
     2917</t>
     2918<t>
     2919   Previous revisions of HTTP gave a specific number of connections as a
     2920   ceiling, but this was found to be impractical for many applications. As a
     2921   result, this specification does not mandate a particular maximum number of
     2922   connections, but instead encourages clients to be conservative when opening
     2923   multiple connections.
     2924</t>
     2925<t>
     2926   In particular, while using multiple connections avoids the "head-of-line
     2927   blocking" problem (whereby a request that takes significant server-side
     2928   processing and/or has a large payload can block subsequent requests on the
     2929   same connection), each connection used consumes server resources (sometimes
     2930   significantly), and furthermore using multiple connections can cause
     2931   undesirable side effects in congested networks.
     2932</t>
     2933<t>
     2934   Note that servers might reject traffic that they deem abusive, including an
     2935   excessive number of connections from a client.
     2936</t>
     2937</section>
     2938
     2939<section title="Failures and Time-outs" anchor="persistent.failures">
     2940<t>
     2941   Servers will usually have some time-out value beyond which they will
     2942   no longer maintain an inactive connection. Proxy servers might make
     2943   this a higher value since it is likely that the client will be making
     2944   more connections through the same server. The use of persistent
     2945   connections places no requirements on the length (or existence) of
     2946   this time-out for either the client or the server.
     2947</t>
     2948<t>
     2949   When a client or server wishes to time-out it &SHOULD; issue a graceful
     2950   close on the transport connection. Clients and servers &SHOULD; both
     2951   constantly watch for the other side of the transport close, and
     2952   respond to it as appropriate. If a client or server does not detect
     2953   the other side's close promptly it could cause unnecessary resource
     2954   drain on the network.
     2955</t>
     2956<t>
     2957   A client, server, or proxy &MAY; close the transport connection at any
     2958   time. For example, a client might have started to send a new request
     2959   at the same time that the server has decided to close the "idle"
     2960   connection. From the server's point of view, the connection is being
     2961   closed while it was idle, but from the client's point of view, a
     2962   request is in progress.
     2963</t>
    29852964<t>
    29862965   HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's
    … …  
    29892968   The latter technique can exacerbate network congestion.
    29902969</t>
    2991 </section>
    2992 
    2993 <section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">
    29942970<t>
    29952971   An HTTP/1.1 (or later) client sending a message body &SHOULD; monitor
    29962972   the network connection for an error status code while it is transmitting
    29972973   the request. If the client sees an error status code, it &SHOULD;
    2998    immediately cease transmitting the body. If the body is being sent
    2999    using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
    3000    empty trailer &MAY; be used to prematurely mark the end of the message.
    3001    If the body was preceded by a Content-Length header field, the client &MUST;
    3002    close the connection.
    3003 </t>
     2974   immediately cease transmitting the body and close the connection.
     2975</t>
     2976</section>
     2977   
     2978<section title="Tear-down" anchor="persistent.tear-down">
     2979<t>
     2980   Persistent connections provide a mechanism by which a client and a
     2981   server can signal the close of a TCP connection. This signaling takes
     2982   place using the <x:ref>Connection</x:ref> header field
     2983   (<xref target="header.connection"/>). Once a close has been signaled, the
     2984   client &MUST-NOT; send any more requests on that
     2985   connection.
     2986</t>
     2987<t>
     2988   If either the client or the server sends the "close" option in the
     2989   <x:ref>Connection</x:ref> header field, that request/response pair
     2990   becomes the last one for the connection.
     2991</t>
     2992<t>
     2993   If the server chooses to close the connection immediately after sending the
     2994   response, it &SHOULD; send a Connection header field including the
     2995   connection option "close".
     2996</t>
     2997<t>
     2998   In case the client does not want to maintain a connection for more
     2999   than that request, it &SHOULD; send a Connection header field including the
     3000   connection option "close".
     3001</t>
     3002<t>
     3003   If the client is sending data, a server implementation using TCP
     3004   &SHOULD; be careful to ensure that the client acknowledges receipt of
     3005   the packet(s) containing the response, before the server closes the
     3006   input connection. If the client continues sending data to the server
     3007   after the close, the server's TCP stack will send a reset packet to
     3008   the client, which might erase the client's unacknowledged input buffers
     3009   before they can be read and interpreted by the HTTP application.
     3010</t>
     3011</section>
    30043012</section>
    30053013
    … …  
    31133121  </list>
    31143122</t>
    3115 </section>
    3116 
    3117 <section title="Closing Connections on Error" anchor="closing.connections.on.error">
    3118 <t>
    3119    If the client is sending data, a server implementation using TCP
    3120    &SHOULD; be careful to ensure that the client acknowledges receipt of
    3121    the packet(s) containing the response, before the server closes the
    3122    input connection. If the client continues sending data to the server
    3123    after the close, the server's TCP stack will send a reset packet to
    3124    the client, which might erase the client's unacknowledged input buffers
    3125    before they can be read and interpreted by the HTTP application.
    3126 </t>
    3127 </section>
    3128 
    31293123</section>
    31303124
    … …  
    48634857  Remove requirements about when servers are allowed to close connections
    48644858  prematurely.
    4865   (<xref target="persistent.practical"/>)
     4859  (<xref target="persistent.connections"/>)
    48664860</t>
    48674861<t>
    48684862  Remove requirement to retry requests under certain circumstances when the
    48694863  server prematurely closes the connection.
    4870   (<xref target="message.transmission.requirements"/>)
     4864  (<xref target="persistent.reuse"/>)
    48714865</t>
    48724866<t>
Note: See TracChangeset for help on using the changeset viewer.