Changeset 2033
- Timestamp:
- 06/12/12 11:51:08 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2032 r2033 449 449 } 450 450 @bottom-center { 451 content: "Expires June 8, 2013";451 content: "Expires June 9, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 5">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-06"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 5, 2012</td>522 <td class="right">December 6, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 8, 2013</td>525 <td class="left">Expires: June 9, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 8, 2013.</p>553 <p>This Internet-Draft will expire on June 9, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 646 646 <li><a href="#rfc.section.6.1">6.1</a> <a href="#header.connection">Connection</a></li> 647 647 <li><a href="#rfc.section.6.2">6.2</a> <a href="#persistent.establishment">Establishment</a></li> 648 <li><a href="#rfc.section.6.3">6.3</a> <a href="#persistent.connections">Persistence</a></li> 649 <li><a href="#rfc.section.6.4">6.4</a> <a href="#persistent.reuse">Reuse</a><ul> 650 <li><a href="#rfc.section.6.4.1">6.4.1</a> <a href="#pipelining">Pipelining</a></li> 651 <li><a href="#rfc.section.6.4.2">6.4.2</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 648 <li><a href="#rfc.section.6.3">6.3</a> <a href="#persistent.connections">Persistence</a><ul> 649 <li><a href="#rfc.section.6.3.1">6.3.1</a> <a href="#pipelining">Pipelining</a></li> 650 <li><a href="#rfc.section.6.3.2">6.3.2</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 652 651 </ul> 653 652 </li> 654 <li><a href="#rfc.section.6. 5">6.5</a> <a href="#persistent.concurrency">Concurrency</a></li>655 <li><a href="#rfc.section.6. 6">6.6</a> <a href="#persistent.failures">Failures and Time-outs</a></li>656 <li><a href="#rfc.section.6. 7">6.7</a> <a href="#persistent.tear-down">Tear-down</a></li>657 <li><a href="#rfc.section.6. 8">6.8</a> <a href="#header.upgrade">Upgrade</a></li>653 <li><a href="#rfc.section.6.4">6.4</a> <a href="#persistent.concurrency">Concurrency</a></li> 654 <li><a href="#rfc.section.6.5">6.5</a> <a href="#persistent.failures">Failures and Time-outs</a></li> 655 <li><a href="#rfc.section.6.6">6.6</a> <a href="#persistent.tear-down">Tear-down</a></li> 656 <li><a href="#rfc.section.6.7">6.7</a> <a href="#header.upgrade">Upgrade</a></li> 658 657 </ul> 659 658 </li> … … 678 677 <li><a href="#rfc.section.8.4">8.4</a> <a href="#dns.related.attacks">DNS-related Attacks</a></li> 679 678 <li><a href="#rfc.section.8.5">8.5</a> <a href="#attack.intermediaries">Intermediaries and Caching</a></li> 680 <li><a href="#rfc.section.8.6">8.6</a> <a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li> 679 <li><a href="#rfc.section.8.6">8.6</a> <a href="#attack.protocol.element.size.overflows">Buffer Overflows</a></li> 680 <li><a href="#rfc.section.8.7">8.7</a> <a href="#message.integrity">Message Integrity</a></li> 681 681 </ul> 682 682 </li> … … 1398 1398 </p> 1399 1399 <p id="rfc.section.3.3.2.p.9">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of 1400 an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title=" Protocol Element SizeOverflows">Section 8.6</a>).1400 an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section 8.6</a>). 1401 1401 </p> 1402 1402 <p id="rfc.section.3.3.2.p.10">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, … … 1479 1479 </p> 1480 1480 <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding 1481 a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. If a response terminates in the middle of the header block (before the empty line is received) 1482 and the status code might rely on header fields to convey the full meaning of the response, then the client cannot assume 1483 that meaning has been conveyed; the client might need to repeat the request in order to determine what action to take next. 1484 </p> 1485 <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has 1481 a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. 1482 </p> 1483 <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header block (before the empty line is received) and the status code might rely 1484 on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed; 1485 the client might need to repeat the request in order to determine what action to take next. 1486 </p> 1487 <p id="rfc.section.3.4.p.4">A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has 1486 1488 not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response 1487 1489 that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered 1488 1490 complete regardless of the number of message body octets received, provided that the header block was received intact. 1489 </p>1490 <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that1491 an error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.1492 </p>1493 <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 data1494 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 multiple1495 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.4.1</a>.1496 1491 </p> 1497 1492 <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> … … 1846 1841 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1847 1842 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a> 1848 ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6. 8</a>1843 ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.7</a> 1849 1844 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 1850 1845 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1976 1971 </p> 1977 1972 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 1978 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6. 7</a>).1973 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.6</a>). 1979 1974 </p> 1980 1975 <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every request message. … … 2001 1996 <li>The connection will close after the current response.</li> 2002 1997 </ul> 2003 <p id="rfc.section.6.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> maintain a persistent connection with an HTTP/1.0 client (see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).2004 </p> 2005 <p id="rfc.section.6.3.p.4"> In order to remain persistent, all messages on a connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>.2006 </p> 2007 < h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="persistent.reuse" href="#persistent.reuse">Reuse</a></h2>2008 <p id="rfc.section.6.4.p.1">A server <em class="bcp14">MAY</em> assume that an HTTP/1.1 client intends to maintain a persistent connection until a <a href="#header.connection" class="smpl">close</a> connection option is received in arequest.2009 </p> 2010 <p id="rfc.section.6. 4.p.2">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option.2011 </p> 2012 <p id="rfc.section.6. 4.p.3">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.2013 </p> 2014 <h3 id="rfc.section.6. 4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <a id="pipelining" href="#pipelining">Pipelining</a></h3>2015 <p id="rfc.section.6. 4.1.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.2016 </p> 2017 <p id="rfc.section.6. 4.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.2018 </p> 2019 <p id="rfc.section.6. 4.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1998 <p id="rfc.section.6.3.p.3">A server <em class="bcp14">MAY</em> assume that an HTTP/1.1 client intends to maintain a persistent connection until a <a href="#header.connection" class="smpl">close</a> connection option is received in a request. 1999 </p> 2000 <p id="rfc.section.6.3.p.4">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option. 2001 </p> 2002 <p id="rfc.section.6.3.p.5">In order to remain persistent, all messages on a connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 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 2003 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. 2004 </p> 2005 <p id="rfc.section.6.3.p.6">A proxy server <em class="bcp14">MUST NOT</em> maintain a persistent connection with an HTTP/1.0 client (see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 2006 </p> 2007 <p id="rfc.section.6.3.p.7">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. 2008 </p> 2009 <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="pipelining" href="#pipelining">Pipelining</a></h3> 2010 <p id="rfc.section.6.3.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. 2011 </p> 2012 <p id="rfc.section.6.3.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. 2013 </p> 2014 <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2020 2015 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. 2021 2016 </p> 2022 <h3 id="rfc.section.6. 4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>2023 <p id="rfc.section.6. 4.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover2017 <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2018 <p id="rfc.section.6.3.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover 2024 2019 from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence 2025 2020 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding 2026 2021 of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails. 2027 2022 </p> 2028 <h2 id="rfc.section.6. 5"><a href="#rfc.section.6.5">6.5</a> <a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h2>2029 <p id="rfc.section.6. 5.p.1">Clients <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server.2030 </p> 2031 <p id="rfc.section.6. 5.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many2023 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h2> 2024 <p id="rfc.section.6.4.p.1">Clients <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server. 2025 </p> 2026 <p id="rfc.section.6.4.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many 2032 2027 applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages 2033 2028 clients to be conservative when opening multiple connections. 2034 2029 </p> 2035 <p id="rfc.section.6. 5.p.3">Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant2030 <p id="rfc.section.6.4.p.3">Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant 2036 2031 server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection 2037 2032 consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks. 2038 2033 </p> 2039 <p id="rfc.section.6. 5.p.4">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>2040 <h2 id="rfc.section.6. 6"><a href="#rfc.section.6.6">6.6</a> <a id="persistent.failures" href="#persistent.failures">Failures and Time-outs</a></h2>2041 <p id="rfc.section.6. 6.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers2034 <p id="rfc.section.6.4.p.4">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> 2035 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="persistent.failures" href="#persistent.failures">Failures and Time-outs</a></h2> 2036 <p id="rfc.section.6.5.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers 2042 2037 might make this a higher value since it is likely that the client will be making more connections through the same server. 2043 2038 The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client 2044 2039 or the server. 2045 2040 </p> 2046 <p id="rfc.section.6. 6.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does2041 <p id="rfc.section.6.5.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 2047 2042 not detect the other side's close promptly it could cause unnecessary resource drain on the network. 2048 2043 </p> 2049 <p id="rfc.section.6. 6.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time2044 <p id="rfc.section.6.5.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 2050 2045 that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed 2051 2046 while it was idle, but from the client's point of view, a request is in progress. 2052 2047 </p> 2053 <p id="rfc.section.6. 6.p.4">Servers <em class="bcp14">SHOULD</em> maintain persistent connections and allow the underlying transport's flow control mechanisms to resolve temporary overloads,2048 <p id="rfc.section.6.5.p.4">Servers <em class="bcp14">SHOULD</em> maintain persistent connections and allow the underlying transport's flow control mechanisms to resolve temporary overloads, 2054 2049 rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network 2055 2050 congestion. 2056 2051 </p> 2057 <p id="rfc.section.6. 6.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error2052 <p id="rfc.section.6.5.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 2058 2053 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection. 2059 2054 </p> 2060 2055 <div id="rfc.iref.c.13"></div> 2061 2056 <div id="rfc.iref.c.14"></div> 2062 <h2 id="rfc.section.6. 7"><a href="#rfc.section.6.7">6.7</a> <a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h2>2063 <p id="rfc.section.6. 7.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.2064 </p> 2065 <p id="rfc.section.6. 7.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request.2066 </p> 2067 <p id="rfc.section.6. 7.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2068 </p> 2069 <p id="rfc.section.6. 7.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2070 </p> 2071 <p id="rfc.section.6. 7.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close;2057 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h2> 2058 <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair. 2059 </p> 2060 <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. 2061 </p> 2062 <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2063 </p> 2064 <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2065 </p> 2066 <p id="rfc.section.6.6.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close; 2072 2067 if additional pipelined requests had been sent on the connection, the client <em class="bcp14">SHOULD</em> assume that they will not be processed by the server. 2073 2068 </p> 2074 <p id="rfc.section.6. 7.p.6">If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able2069 <p id="rfc.section.6.6.p.6">If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able 2075 2070 to read the last HTTP response. If the server receives additional data from the client on a fully-closed connection, such 2076 2071 as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a … … 2078 2073 can be read and interpreted by the client's HTTP parser. 2079 2074 </p> 2080 <p id="rfc.section.6. 7.p.7">To avoid the TCP reset problem, a server can perform a lingering close on a connection by closing only the write side of the2075 <p id="rfc.section.6.6.p.7">To avoid the TCP reset problem, a server can perform a lingering close on a connection by closing only the write side of the 2081 2076 read/write connection (a half-close) and continuing to read from the connection until the connection is closed by the client 2082 2077 or the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing 2083 2078 the server's last response. It is then safe for the server to fully close the connection. 2084 2079 </p> 2085 <p id="rfc.section.6. 7.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p>2080 <p id="rfc.section.6.6.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p> 2086 2081 <div id="rfc.iref.u.5"></div> 2087 <h2 id="rfc.section.6. 8"><a href="#rfc.section.6.8">6.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>2088 <p id="rfc.section.6. 8.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol2082 <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2083 <p id="rfc.section.6.7.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol 2089 2084 on the same connection. A client <em class="bcp14">MAY</em> send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols 2090 2085 before sending the final response. A server <em class="bcp14">MUST</em> send an Upgrade header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching … … 2097 2092 <a href="#header.upgrade" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2098 2093 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2099 </pre><p id="rfc.section.6. 8.p.3">For example,</p>2094 </pre><p id="rfc.section.6.7.p.3">For example,</p> 2100 2095 <div id="rfc.figure.u.58"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2101 </pre><p id="rfc.section.6. 8.p.5">Upgrade eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the2096 </pre><p id="rfc.section.6.7.p.5">Upgrade eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the 2102 2097 more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available 2103 2098 (where "better" is determined by the server, possibly according to the nature of the request method or target resource). 2104 2099 </p> 2105 <p id="rfc.section.6. 8.p.6">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities2100 <p id="rfc.section.6.7.p.6">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2106 2101 and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol chosen, 2107 2102 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field. 2108 2103 </p> 2109 <p id="rfc.section.6. 8.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it <em class="bcp14">MUST</em> first respond with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follow that with the new protocol's equivalent of a response to a GET on the target2104 <p id="rfc.section.6.7.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it <em class="bcp14">MUST</em> first respond with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follow that with the new protocol's equivalent of a response to a GET on the target 2110 2105 resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of 2111 2106 an additional round-trip. A server <em class="bcp14">MUST NOT</em> switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored 2112 2107 by any protocol. 2113 2108 </p> 2114 <p id="rfc.section.6. 8.p.8">When Upgrade is sent, a sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries2109 <p id="rfc.section.6.7.p.8">When Upgrade is sent, a sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries 2115 2110 that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request. 2116 2111 </p> 2117 <p id="rfc.section.6. 8.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used2112 <p id="rfc.section.6.7.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used 2118 2113 to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2119 2114 </p> 2120 <p id="rfc.section.6. 8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2115 <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2121 2116 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2122 2117 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. … … 2187 2182 <td class="left">http</td> 2188 2183 <td class="left">standard</td> 2189 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6. 8</a>2184 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.7</a> 2190 2185 </td> 2191 2186 </tr> … … 2525 2520 this problem. 2526 2521 </p> 2527 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows"> Protocol Element SizeOverflows</a></h2>2522 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Buffer Overflows</a></h2> 2528 2523 <p id="rfc.section.8.6.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform 2529 2524 a Denial of Service against implementations that accept fields with unlimited lengths. … … 2536 2531 <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status 2537 2532 phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability. 2533 </p> 2534 <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="message.integrity" href="#message.integrity">Message Integrity</a></h2> 2535 <p id="rfc.section.8.7.p.1">HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of 2536 underlying transport protocols and the use of length or chunk-delimited framing to detect completeness. Additional integrity 2537 mechanisms, such as hash functions or digital signatures applied to the content, can be selectively added to messages via 2538 extensible metadata header fields. Historically, the lack of a single integrity mechanism has been justified by the informal 2539 nature of most HTTP communication. However, the prevalence of HTTP as an information access mechanism has resulted in its 2540 increasing use within environments where verification of message integrity is crucial. 2541 </p> 2542 <p id="rfc.section.8.7.p.2">User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such 2543 that those means can be enabled within environments for which integrity is necessary. For example, a browser being used to 2544 view medical history or drug interaction information needs to indicate to the user when such information is detected by the 2545 protocol to be incomplete, expired, or corrupted during transfer. Such mechanisms might be selectively enabled via user agent 2546 extensions or the presence of message integrity metadata in a response. At a minimum, user agents ought to provide some indication 2547 that allows a user to distinguish between a complete and incomplete response message (<a href="#incomplete.messages" title="Handling Incomplete Messages">Section 3.4</a>) when such verification is desired. 2538 2548 </p> 2539 2549 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> … … 2883 2893 </p> 2884 2894 <p id="rfc.section.A.2.p.30">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. 2885 (<a href="#persistent. reuse" title="Reuse">Section 6.4</a>)2895 (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2886 2896 </p> 2887 2897 <p id="rfc.section.A.2.p.31">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2888 2898 </p> 2889 <p id="rfc.section.A.2.p.32">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6. 8</a>)2899 <p id="rfc.section.A.2.p.32">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.7</a>) 2890 2900 </p> 2891 2901 <p id="rfc.section.A.2.p.33">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>) … … 3086 3096 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li> 3087 3097 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3088 <li>close <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6. 7</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">6.8</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3098 <li>close <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.6">6.6</a>, <a href="#rfc.xref.header.connection.7">6.7</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3089 3099 <li>compress (Coding Format) <a href="#rfc.iref.c.10">4.2.1</a></li> 3090 3100 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3091 <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.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6. 7</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">6.8</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3101 <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.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.6">6.6</a>, <a href="#rfc.xref.header.connection.7">6.7</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3092 3102 <li>Content-Length header field <a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li> 3093 3103 </ul> … … 3190 3200 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3191 3201 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3192 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6. 8</b></a></li>3202 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.7</b></a></li> 3193 3203 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3194 3204 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> … … 3245 3255 </li> 3246 3256 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3247 <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</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.6</a>, <a href="#rfc.xref.Part2.21">5.7.2</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6. 4.1</a>, <a href="#rfc.xref.Part2.28">6.4.2</a>, <a href="#rfc.xref.Part2.29">6.8</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3257 <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</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.6</a>, <a href="#rfc.xref.Part2.21">5.7.2</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3248 3258 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3249 3259 <li><em>Section 3.1.1.5</em> <a href="#rfc.xref.Part2.26">5.7.2</a></li> … … 3253 3263 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.21">5.7.2</a></li> 3254 3264 <li><em>Section 5</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3255 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.27">6. 4.1</a>, <a href="#rfc.xref.Part2.28">6.4.2</a></li>3265 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a></li> 3256 3266 <li><em>Section 5.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.2</a></li> 3257 3267 <li><em>Section 5.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.18">5.3</a></li> … … 3261 3271 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.20">5.6</a></li> 3262 3272 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3263 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.29">6. 8</a></li>3273 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.29">6.7</a></li> 3264 3274 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2.32">8.6</a></li> 3265 3275 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">8.6</a></li> … … 3384 3394 </li> 3385 3395 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3386 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">5.7.1</a>, <a href="#rfc.iref.u.5"><b>6. 8</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3396 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">5.7.1</a>, <a href="#rfc.iref.u.5"><b>6.7</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3387 3397 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3388 3398 <li>URI scheme -
draft-ietf-httpbis/latest/p1-messaging.xml
r2032 r2033 1762 1762 when a connection is closed prematurely or when decoding a supposedly 1763 1763 chunked transfer coding fails, &MUST; record the message as incomplete. 1764 Cache requirements for incomplete responses are defined in 1765 &cache-incomplete;. 1766 </t> 1767 <t> 1764 1768 If a response terminates in the middle of the header block (before the 1765 1769 empty line is received) and the status code might rely on header fields to … … 1778 1782 message body octets received, provided that the header block was received 1779 1783 intact. 1780 </t>1781 <t>1782 A user agent &MUST-NOT; render an incomplete response message body as if1783 it were complete (i.e., some indication needs to be given to the user that an1784 error occurred). Cache requirements for incomplete responses are defined1785 in &cache-incomplete;.1786 </t>1787 <t>1788 A server &MUST; read the entire request message body or close1789 the connection after sending its response, since otherwise the1790 remaining data on a persistent connection would be misinterpreted1791 as the next request. Likewise,1792 a client &MUST; read the entire response message body if it intends1793 to reuse the same connection for a subsequent request. Pipelining1794 multiple requests on a connection is described in <xref target="pipelining"/>.1795 1784 </t> 1796 1785 </section> … … 2823 2812 </t> 2824 2813 <t> 2814 A server &MAY; assume that an HTTP/1.1 client intends to maintain a 2815 persistent connection until a <x:ref>close</x:ref> connection option 2816 is received in a request. 2817 </t> 2818 <t> 2819 A client &MAY; reuse a persistent connection until it sends or receives 2820 a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response 2821 without a "keep-alive" connection option. 2822 </t> 2823 <t> 2824 In order to remain persistent, all messages on a connection &MUST; 2825 have a self-defined message length (i.e., one not defined by closure 2826 of the connection), as described in <xref target="message.body"/>. 2827 A server &MUST; read the entire request message body or close 2828 the connection after sending its response, since otherwise the 2829 remaining data on a persistent connection would be misinterpreted 2830 as the next request. Likewise, 2831 a client &MUST; read the entire response message body if it intends 2832 to reuse the same connection for a subsequent request. 2833 </t> 2834 <t> 2825 2835 A proxy server &MUST-NOT; maintain a persistent connection with an 2826 2836 HTTP/1.0 client (see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> for 2827 2837 information and discussion of the problems with the Keep-Alive header field 2828 2838 implemented by many HTTP/1.0 clients). 2829 </t>2830 <t>2831 In order to remain persistent, all messages on a connection &MUST;2832 have a self-defined message length (i.e., one not defined by closure2833 of the connection), as described in <xref target="message.body"/>.2834 </t>2835 </section>2836 2837 <section title="Reuse" anchor="persistent.reuse">2838 <t>2839 A server &MAY; assume that an HTTP/1.1 client intends to maintain a2840 persistent connection until a <x:ref>close</x:ref> connection option2841 is received in a request.2842 </t>2843 <t>2844 A client &MAY; reuse a persistent connection until it sends or receives2845 a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response2846 without a "keep-alive" connection option.2847 2839 </t> 2848 2840 <t> … … 3610 3602 </section> 3611 3603 3612 <section title=" Protocol Element SizeOverflows" anchor="attack.protocol.element.size.overflows">3604 <section title="Buffer Overflows" anchor="attack.protocol.element.size.overflows"> 3613 3605 <t> 3614 3606 Because HTTP uses mostly textual, character-delimited fields, attackers can … … 3635 3627 phrases, header field-names, and body chunks, so as to avoid denial of 3636 3628 service attacks without impeding interoperability. 3629 </t> 3630 </section> 3631 3632 <section title="Message Integrity" anchor="message.integrity"> 3633 <t> 3634 HTTP does not define a specific mechanism for ensuring message integrity, 3635 instead relying on the error-detection ability of underlying transport 3636 protocols and the use of length or chunk-delimited framing to detect 3637 completeness. Additional integrity mechanisms, such as hash functions or 3638 digital signatures applied to the content, can be selectively added to 3639 messages via extensible metadata header fields. Historically, the lack of 3640 a single integrity mechanism has been justified by the informal nature of 3641 most HTTP communication. However, the prevalence of HTTP as an information 3642 access mechanism has resulted in its increasing use within environments 3643 where verification of message integrity is crucial. 3644 </t> 3645 <t> 3646 User agents are encouraged to implement configurable means for detecting 3647 and reporting failures of message integrity such that those means can be 3648 enabled within environments for which integrity is necessary. For example, 3649 a browser being used to view medical history or drug interaction 3650 information needs to indicate to the user when such information is detected 3651 by the protocol to be incomplete, expired, or corrupted during transfer. 3652 Such mechanisms might be selectively enabled via user agent extensions or 3653 the presence of message integrity metadata in a response. 3654 At a minimum, user agents ought to provide some indication that allows a 3655 user to distinguish between a complete and incomplete response message 3656 (<xref target="incomplete.messages"/>) when such verification is desired. 3637 3657 </t> 3638 3658 </section> … … 4840 4860 The requirement to retry requests under certain circumstances when the 4841 4861 server prematurely closes the connection has been removed. 4842 (<xref target="persistent. reuse"/>)4862 (<xref target="persistent.connections"/>) 4843 4863 </t> 4844 4864 <t>
Note: See TracChangeset
for help on using the changeset viewer.