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

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

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.