Changeset 2033


Ignore:
Timestamp:
06/12/12 11:51:08 (9 years ago)
Author:
fielding@…
Message:

Move new user agent requirement on rendering incomplete responses to
a suggestion in security considerations. Addresses #408 and #415

Consolidate more stuff on persistent connection reuse. Addresses #396

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

Legend:

Unmodified
Added
Removed

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

    r2032 r2033  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 8, 2013";
     451       content: "Expires June 9, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-05">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-06">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 5, 2012</td>
     522               <td class="right">December 6, 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: June 8, 2013</td>
     525               <td class="left">Expires: June 9, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </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>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    646646               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    647647               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li>
    648                <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a></li>
    649                <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.reuse">Reuse</a><ul>
    650                      <li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    651                      <li><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
     648               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a><ul>
     649                     <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     650                     <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
    652651                  </ul>
    653652               </li>
    654                <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li>
    655                <li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Time-outs</a></li>
    656                <li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li>
    657                <li><a href="#rfc.section.6.8">6.8</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
     653               <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li>
     654               <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Time-outs</a></li>
     655               <li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li>
     656               <li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
    658657            </ul>
    659658         </li>
    … …  
    678677               <li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
    679678               <li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#attack.intermediaries">Intermediaries and Caching</a></li>
    680                <li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li>
     679               <li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Buffer Overflows</a></li>
     680               <li><a href="#rfc.section.8.7">8.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li>
    681681            </ul>
    682682         </li>
    … …  
    13981398      </p>
    13991399      <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 Size Overflows">Section&nbsp;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&nbsp;8.6</a>).
    14011401      </p>
    14021402      <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,
    … …  
    14791479      </p>
    14801480      <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
    14861488         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
    14871489         that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered
    14881490         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 that
    1491          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 data
    1494          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
    1495          requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.4.1</a>.
    14961491      </p>
    14971492      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    … …  
    18461841                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    18471842  <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&nbsp;6.8</a>
     1843                      ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.7</a>
    18491844  <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>
    18501845  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    … …  
    19761971      </p>
    19771972      <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&nbsp;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&nbsp;6.6</a>).
    19791974      </p>
    19801975      <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.
    … …  
    20011996         <li>The connection will close after the current response.</li>
    20021997      </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&nbsp;3.3</a>.
    2006       </p>
    2007       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<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 a request.
    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&nbsp;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>&nbsp;<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 to
     1998      <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&nbsp;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&nbsp;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>&nbsp;<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
    20202015         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.
    20212016      </p>
    2022       <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<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 recover
     2017      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<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
    20242019         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
    20252020         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
    20262021         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.
    20272022      </p>
    2028       <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<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 many
     2023      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<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
    20322027         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    20332028         clients to be conservative when opening multiple connections.
    20342029      </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 significant
     2030      <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
    20362031         server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection
    20372032         consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks.
    20382033      </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>&nbsp;<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 servers
     2034      <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>&nbsp;<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
    20422037         might make this a higher value since it is likely that the client will be making more connections through the same server.
    20432038         The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
    20442039         or the server.
    20452040      </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 does
     2041      <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
    20472042         not detect the other side's close promptly it could cause unnecessary resource drain on the network.
    20482043      </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 time
     2044      <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
    20502045         that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
    20512046         while it was idle, but from the client's point of view, a request is in progress.
    20522047      </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,
    20542049         rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network
    20552050         congestion.
    20562051      </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 error
     2052      <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
    20582053         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection.
    20592054      </p>
    20602055      <div id="rfc.iref.c.13"></div>
    20612056      <div id="rfc.iref.c.14"></div>
    2062       <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<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&nbsp;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>&nbsp;<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&nbsp;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;
    20722067         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.
    20732068      </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 able
     2069      <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
    20752070         to read the last HTTP response. If the server receives additional data from the client on a fully-closed connection, such
    20762071         as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a
    … …  
    20782073         can be read and interpreted by the client's HTTP parser.
    20792074      </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 the
     2075      <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
    20812076         read/write connection (a half-close) and continuing to read from the connection until the connection is closed by the client
    20822077         or the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing
    20832078         the server's last response. It is then safe for the server to fully close the connection.
    20842079      </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>
    20862081      <div id="rfc.iref.u.5"></div>
    2087       <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<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 protocol
     2082      <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<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
    20892084         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
    20902085         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
    … …  
    20972092  <a href="#header.upgrade" class="smpl">protocol-name</a>    = <a href="#rule.token.separators" class="smpl">token</a>
    20982093  <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>
    21002095      <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 the
     2096</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
    21022097         more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available
    21032098         (where "better" is determined by the server, possibly according to the nature of the request method or target resource).
    21042099      </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 capabilities
     2100      <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
    21062101         and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol chosen,
    21072102         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.
    21082103      </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 target
     2104      <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
    21102105         resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of
    21112106         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
    21122107         by any protocol.
    21132108      </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&nbsp;6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
     2109      <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&nbsp;6.1</a>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
    21152110         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.
    21162111      </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 used
     2112      <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
    21182113         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>).
    21192114      </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 defined
     2115      <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
    21212116         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    21222117         in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
    … …  
    21872182                  <td class="left">http</td>
    21882183                  <td class="left">standard</td>
    2189                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.8</a>
     2184                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.7</a>
    21902185                  </td>
    21912186               </tr>
    … …  
    25252520         this problem.
    25262521      </p>
    2527       <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>
     2522      <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Buffer Overflows</a></h2>
    25282523      <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
    25292524         a Denial of Service against implementations that accept fields with unlimited lengths.
    … …  
    25362531      <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
    25372532         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>&nbsp;<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&nbsp;3.4</a>) when such verification is desired.
    25382548      </p>
    25392549      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    … …  
    28832893      </p>
    28842894      <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&nbsp;6.4</a>)
     2895         (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
    28862896      </p>
    28872897      <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&nbsp;6.3</a>)
    28882898      </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&nbsp;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&nbsp;6.7</a>)
    28902900      </p>
    28912901      <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&nbsp;7.4</a>)
    … …  
    30863096                  <li>chunked (Coding Format)&nbsp;&nbsp;<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>
    30873097                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3088                   <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.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&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.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>
    30893099                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
    30903100                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3091                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.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&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.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>
    30923102                  <li>Content-Length header field&nbsp;&nbsp;<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>
    30933103               </ul>
    … …  
    31903200                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    31913201                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    3192                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.8</b></a></li>
     3202                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.7</b></a></li>
    31933203                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    31943204                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    … …  
    32453255            </li>
    32463256            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3247                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</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>
    32483258                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    32493259                        <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
    … …  
    32533263                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.7.2</a></li>
    32543264                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3255                         <li><em>Section 5.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a></li>
    32563266                        <li><em>Section 5.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.2</a></li>
    32573267                        <li><em>Section 5.3.6</em>&nbsp;&nbsp;<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>
    … …  
    32613271                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.6</a></li>
    32623272                        <li><em>Section 7.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3263                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.8</a></li>
     3273                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.7</a></li>
    32643274                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">8.6</a></li>
    32653275                        <li><em>Section 7.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">8.6</a></li>
    … …  
    33843394            </li>
    33853395            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3386                   <li>Upgrade header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    33873397                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    33883398                  <li>URI scheme&nbsp;&nbsp;

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

    r2032 r2033  
    17621762   when a connection is closed prematurely or when decoding a supposedly
    17631763   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>
    17641768   If a response terminates in the middle of the header block (before the
    17651769   empty line is received) and the status code might rely on header fields to
    … …  
    17781782   message body octets received, provided that the header block was received
    17791783   intact.
    1780 </t>
    1781 <t>
    1782    A user agent &MUST-NOT; render an incomplete response message body as if
    1783    it were complete (i.e., some indication needs to be given to the user that an
    1784    error occurred).  Cache requirements for incomplete responses are defined
    1785    in &cache-incomplete;.
    1786 </t>
    1787 <t>
    1788    A server &MUST; read the entire request message body or close
    1789    the connection after sending its response, since otherwise the
    1790    remaining data on a persistent connection would be misinterpreted
    1791    as the next request.  Likewise,
    1792    a client &MUST; read the entire response message body if it intends
    1793    to reuse the same connection for a subsequent request.  Pipelining
    1794    multiple requests on a connection is described in <xref target="pipelining"/>.
    17951784</t>
    17961785</section>
    … …  
    28232812</t>
    28242813<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>
    28252835   A proxy server &MUST-NOT; maintain a persistent connection with an
    28262836   HTTP/1.0 client (see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> for
    28272837   information and discussion of the problems with the Keep-Alive header field
    28282838   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 closure
    2833    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 a
    2840    persistent connection until a <x:ref>close</x:ref> connection option
    2841    is received in a request.
    2842 </t>
    2843 <t>
    2844    A client &MAY; reuse a persistent connection until it sends or receives
    2845    a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response
    2846    without a "keep-alive" connection option.
    28472839</t>
    28482840<t>
    … …  
    36103602</section>
    36113603
    3612 <section title="Protocol Element Size Overflows" anchor="attack.protocol.element.size.overflows">
     3604<section title="Buffer Overflows" anchor="attack.protocol.element.size.overflows">
    36133605<t>
    36143606   Because HTTP uses mostly textual, character-delimited fields, attackers can
    … …  
    36353627   phrases, header field-names, and body chunks, so as to avoid denial of
    36363628   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.
    36373657</t>
    36383658</section>
    … …  
    48404860  The requirement to retry requests under certain circumstances when the
    48414861  server prematurely closes the connection has been removed.
    4842   (<xref target="persistent.reuse"/>)
     4862  (<xref target="persistent.connections"/>)
    48434863</t>
    48444864<t>
Note: See TracChangeset for help on using the changeset viewer.