Changeset 1838 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 20/08/12 08:33:10 (10 years ago)
- File:
-
- 1 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>
Note: See TracChangeset
for help on using the changeset viewer.