Changeset 1838 for draft-ietf-httpbis
- Timestamp:
- 20/08/12 08:33:10 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1837 r1838 449 449 } 450 450 @bottom-center { 451 content: "Expires February 2 0, 2013";451 content: "Expires February 21, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <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"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: February 2 0, 2013</td>526 <td class="left">Expires: February 21, 2013</td> 527 527 <td class="right">greenbytes</td> 528 528 </tr> 529 529 <tr> 530 530 <td class="left"></td> 531 <td class="right">August 19, 2012</td>531 <td class="right">August 20, 2012</td> 532 532 </tr> 533 533 </tbody> … … 556 556 in progress”. 557 557 </p> 558 <p>This Internet-Draft will expire on February 2 0, 2013.</p>558 <p>This Internet-Draft will expire on February 21, 2013.</p> 559 559 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 560 560 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 647 647 <li><a href="#rfc.section.6.1">6.1</a> <a href="#header.connection">Connection</a></li> 648 648 <li><a href="#rfc.section.6.2">6.2</a> <a href="#persistent.connections">Persistent Connections</a><ul> 649 <li><a href="#rfc.section.6.2.1">6.2.1</a> <a href="#persistent.overall">Overall Operation</a><ul> 650 <li><a href="#rfc.section.6.2.1.1">6.2.1.1</a> <a href="#persistent.negotiation">Negotiation</a></li> 651 <li><a href="#rfc.section.6.2.1.2">6.2.1.2</a> <a href="#pipelining">Pipelining</a></li> 649 <li><a href="#rfc.section.6.2.1">6.2.1</a> <a href="#persistent.establishment">Establishment</a></li> 650 <li><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#persistent.reuse">Reuse</a><ul> 651 <li><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a href="#pipelining">Pipelining</a></li> 652 <li><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 652 653 </ul> 653 654 </li> 654 <li><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#persistent.practical">Practical Considerations</a></li> 655 <li><a href="#rfc.section.6.2.3">6.2.3</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 655 <li><a href="#rfc.section.6.2.3">6.2.3</a> <a href="#persistent.concurrency">Concurrency</a></li> 656 <li><a href="#rfc.section.6.2.4">6.2.4</a> <a href="#persistent.failures">Failures and Time-outs</a></li> 657 <li><a href="#rfc.section.6.2.5">6.2.5</a> <a href="#persistent.tear-down">Tear-down</a></li> 656 658 </ul> 657 659 </li> 658 <li><a href="#rfc.section.6.3">6.3</a> <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul> 659 <li><a href="#rfc.section.6.3.1">6.3.1</a> <a href="#persistent.flow">Persistent Connections and Flow Control</a></li> 660 <li><a href="#rfc.section.6.3.2">6.3.2</a> <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> <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> <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> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li> 665 661 <li><a href="#rfc.section.6.4">6.4</a> <a href="#header.upgrade">Upgrade</a></li> 666 662 </ul> … … 1506 1502 <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 1507 1503 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 6.2. 1.2</a>.1504 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.2.2.1</a>. 1509 1505 </p> 1510 1506 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> … … 1984 1980 connection option, since it would be unwise for senders to use that field-name for anything else. 1985 1981 </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, 1988 1983 </p> 1989 1984 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close … … 2000 1995 However, these extensions were insufficient for dynamically generated responses and difficult to use with intermediaries. 2001 1996 </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 number2003 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: 2004 1999 </p> 2005 2000 <ul> … … 2021 2016 <p id="rfc.section.6.2.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. 2022 2017 </p> 2023 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <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 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> <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 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 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> <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> <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 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> <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 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> <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 2053 2040 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. 2054 2041 </p> 2055 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <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> <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> <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> <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 2057 2062 might make this a higher value since it is likely that the client will be making more connections through the same server. 2058 2063 The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client 2059 2064 or the server. 2060 2065 </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 does2066 <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 2062 2067 not detect the other side's close promptly it could cause unnecessary resource drain on the network. 2063 2068 </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 time2069 <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 2065 2070 that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed 2066 2071 while it was idle, but from the client's point of view, a request is in progress. 2067 2072 </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> <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> <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> <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 2088 2074 connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. 2089 2075 </p> 2090 <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <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 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> <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> <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 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> <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 2096 2096 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2097 2097 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without 2098 2098 looking at the body. 2099 2099 </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> 2101 2101 <ul> 2102 2102 <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. … … 2105 2105 </li> 2106 2106 </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: 2108 2108 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 2109 2109 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. 2110 2110 </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> 2112 2112 <ul> 2113 2113 <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. … … 2129 2129 </li> 2130 2130 </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> 2132 2132 <ul> 2133 2133 <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 … … 2141 2141 </li> 2142 2142 </ul> 2143 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <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 closes2145 the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send2146 a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted2147 by the HTTP application.2148 </p>2149 2143 <div id="rfc.iref.u.5"></div> 2150 2144 <div id="rfc.iref.h.14"></div> … … 2906 2900 </p> 2907 2901 <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 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 6.3</a>)2902 Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.connections" title="Persistent Connections">Section 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 6.2.2</a>) 2911 2905 </p> 2912 2906 <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value.</p> … … 3502 3496 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3503 3497 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3504 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</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 <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> 3505 3499 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3506 3500 </ul> … … 3619 3613 <li>Header Fields 3620 3614 <ul> 3621 <li>Connection <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 <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> 3622 3616 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3623 3617 <li>Host <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> … … 3670 3664 </li> 3671 3665 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3672 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7.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> <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> 3673 3667 <li><em>Section 2</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3674 <li><em>Section 2.1.2</em> <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> <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a></li> 3675 3669 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3676 3670 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3677 3671 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3678 3672 <li><em>Section 4</em> <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> <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> <a href="#rfc.xref.Part2.24">6.3 .3</a></li>3673 <li><em>Section 4.3</em> <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> <a href="#rfc.xref.Part2.24">6.3</a></li> 3681 3675 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3682 3676 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.27">6.4</a></li> … … 3690 3684 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.20">5.8</a></li> 3691 3685 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3692 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.25">6.3 .3</a></li>3686 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.25">6.3</a></li> 3693 3687 <li><em>Section 9.17</em> <a href="#rfc.xref.Part2.18">5.8</a></li> 3694 3688 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> … … 3734 3728 </li> 3735 3729 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3736 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1 .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> <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> <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> <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li> 3738 3732 </ul> 3739 3733 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1837 r1838 2682 2682 <x:anchor-alias value="Connection"/> 2683 2683 <x:anchor-alias value="connection-option"/> 2684 <x:anchor-alias value="close"/> 2684 2685 <t> 2685 2686 The "Connection" header field allows the sender to indicate desired … … 2748 2749 </t> 2749 2750 <t> 2750 HTTP/1.1 defines the " close" connection option for the sender to2751 s ignal that the connection will be closed after completion of the2752 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, 2753 2754 </t> 2754 2755 <figure><artwork type="example"> … … 2787 2788 HTTP/1.1 defaults to the use of "<x:ref>persistent connections</x:ref>", 2788 2789 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. 2790 2792 Persistent connections have a number of advantages: 2791 2793 <list style="symbols"> … … 2824 2826 HTTP implementations &SHOULD; implement persistent connections. 2825 2827 </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> 2845 2833 <t> 2846 2834 An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to 2847 2835 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. 2852 2837 </t> 2853 2838 <t> … … 2855 2840 decide to keep it open based on whether the response from a server 2856 2841 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". 2865 2843 </t> 2866 2844 <t> … … 2871 2849 </t> 2872 2850 <t> 2873 Each persistent connection applies to only one transport link.2874 </t>2875 <t>2876 2851 A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection 2877 2852 with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> … … 2879 2854 implemented by many HTTP/1.0 clients). 2880 2855 </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> 2881 2864 <t> 2882 2865 In order to remain persistent, all messages on the connection &MUST; … … 2884 2867 of the connection), as described in <xref target="message.body"/>. 2885 2868 </t> 2886 </section>2887 2869 2888 2870 <section title="Pipelining" anchor="pipelining"> … … 2903 2885 </t> 2904 2886 <t> 2905 Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods or2906 non-idempotent sequences of request methods (see &idempotent-methods;). Otherwise, a2907 premature termination of the transport connection could lead to2908 indeterminate results. A client wishing to send a non-idempotent2887 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 2909 2891 request &SHOULD; wait to send that request until it has received the 2910 2892 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 will2918 no longer maintain an inactive connection. Proxy servers might make2919 this a higher value since it is likely that the client will be making2920 more connections through the same server. The use of persistent2921 connections places no requirements on the length (or existence) of2922 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 graceful2926 close on the transport connection. Clients and servers &SHOULD; both2927 constantly watch for the other side of the transport close, and2928 respond to it as appropriate. If a client or server does not detect2929 the other side's close promptly it could cause unnecessary resource2930 drain on the network.2931 </t>2932 <t>2933 A client, server, or proxy &MAY; close the transport connection at any2934 time. For example, a client might have started to send a new request2935 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 being2937 closed while it was idle, but from the client's point of view, a2938 request is in progress.2939 </t>2940 <t>2941 Clients (including proxies) &SHOULD; limit the number of simultaneous2942 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 a2946 ceiling, but this was found to be impractical for many applications. As a2947 result, this specification does not mandate a particular maximum number of2948 connections, but instead encourages clients to be conservative when opening2949 multiple connections.2950 </t>2951 <t>2952 In particular, while using multiple connections avoids the "head-of-line2953 blocking" problem (whereby a request that takes significant server-side2954 processing and/or has a large payload can block subsequent requests on the2955 same connection), each connection used consumes server resources (sometimes2956 significantly), and furthermore using multiple connections can cause2957 undesirable side effects in congested networks.2958 </t>2959 <t>2960 Note that servers might reject traffic that they deem abusive, including an2961 excessive number of connections from a client.2962 2893 </t> 2963 2894 </section> … … 2979 2910 </section> 2980 2911 </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> 2985 2964 <t> 2986 2965 HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's … … 2989 2968 The latter technique can exacerbate network congestion. 2990 2969 </t> 2991 </section>2992 2993 <section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">2994 2970 <t> 2995 2971 An HTTP/1.1 (or later) client sending a message body &SHOULD; monitor 2996 2972 the network connection for an error status code while it is transmitting 2997 2973 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> 3004 3012 </section> 3005 3013 … … 3113 3121 </list> 3114 3122 </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 TCP3120 &SHOULD; be careful to ensure that the client acknowledges receipt of3121 the packet(s) containing the response, before the server closes the3122 input connection. If the client continues sending data to the server3123 after the close, the server's TCP stack will send a reset packet to3124 the client, which might erase the client's unacknowledged input buffers3125 before they can be read and interpreted by the HTTP application.3126 </t>3127 </section>3128 3129 3123 </section> 3130 3124 … … 4863 4857 Remove requirements about when servers are allowed to close connections 4864 4858 prematurely. 4865 (<xref target="persistent. practical"/>)4859 (<xref target="persistent.connections"/>) 4866 4860 </t> 4867 4861 <t> 4868 4862 Remove requirement to retry requests under certain circumstances when the 4869 4863 server prematurely closes the connection. 4870 (<xref target=" message.transmission.requirements"/>)4864 (<xref target="persistent.reuse"/>) 4871 4865 </t> 4872 4866 <t>
Note: See TracChangeset
for help on using the changeset viewer.