* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1316


Ignore:
Timestamp:
2011-06-29 02:14:48 (3 years ago)
Author:
julian.reschke@gmx.de
Message:

set expectatiions around buffering (see #283)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1313 r1316  
    359359  }  
    360360  @bottom-center { 
    361        content: "Expires December 29, 2011";  
     361       content: "Expires December 31, 2011";  
    362362  }  
    363363  @bottom-right { 
     
    410410      <meta name="dct.creator" content="Reschke, J. F."> 
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 
    412       <meta name="dct.issued" scheme="ISO8601" content="2011-06-27"> 
     412      <meta name="dct.issued" scheme="ISO8601" content="2011-06-29"> 
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
     
    442442            </tr> 
    443443            <tr> 
    444                <td class="left">Expires: December 29, 2011</td> 
     444               <td class="left">Expires: December 31, 2011</td> 
    445445               <td class="right">HP</td> 
    446446            </tr> 
     
    495495            <tr> 
    496496               <td class="left"></td> 
    497                <td class="right">June 27, 2011</td> 
     497               <td class="right">June 29, 2011</td> 
    498498            </tr> 
    499499         </tbody> 
     
    525525         in progress”. 
    526526      </p> 
    527       <p>This Internet-Draft will expire on December 29, 2011.</p> 
     527      <p>This Internet-Draft will expire on December 31, 2011.</p> 
    528528      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    529529      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    554554         <li>2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP-related architecture</a><ul> 
    555555               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li> 
    556                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li> 
    557                <li>2.3&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li> 
    558                <li>2.4&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li> 
    559                <li>2.5&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li> 
    560                <li>2.6&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul> 
    561                      <li>2.6.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li> 
    562                      <li>2.6.2&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI scheme</a></li> 
    563                      <li>2.6.3&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 
     556               <li>2.2&nbsp;&nbsp;&nbsp;<a href="#message-orientation-and-buffering">Message Orientation and Buffering</a></li> 
     557               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li> 
     558               <li>2.4&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li> 
     559               <li>2.5&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li> 
     560               <li>2.6&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li> 
     561               <li>2.7&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul> 
     562                     <li>2.7.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li> 
     563                     <li>2.7.2&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI scheme</a></li> 
     564                     <li>2.7.3&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 
    564565                  </ul> 
    565566               </li> 
     
    925926 
    926927<span id="exbody">Hello World! 
    927 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2> 
    928       <p id="rfc.section.2.2.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable 
     928</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="message-orientation-and-buffering" href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2> 
     929      <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations 
     930         only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some 
     931         amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide 
     932         other services. 
     933      </p> 
     934      <p id="rfc.section.2.2.p.2">Therefore, extensions to and uses of HTTP cannot rely on the availability of a partial message, or assume that messages will 
     935         not be buffered. There are strategies that can be used to test for buffering in a given connection, but it should be understood 
     936         that behaviors can differ across connections, and between requests and responses. 
     937      </p> 
     938      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2> 
     939      <p id="rfc.section.2.3.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable 
    929940         transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request 
    930941         and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. 
    931942      </p> 
    932       <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's 
    933          URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use 
     943      <p id="rfc.section.2.3.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's 
     944         URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use 
    934945         a proxy via some other connection port or protocol instead of using the defaults. 
    935946      </p> 
    936       <p id="rfc.section.2.2.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>. 
     947      <p id="rfc.section.2.3.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>. 
    937948      </p> 
    938949      <div id="rfc.iref.i.1"></div> 
    939       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 
    940       <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of 
     950      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 
     951      <p id="rfc.section.2.4.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of 
    941952         HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, 
    942953         switching behavior based on the nature of each request. 
     
    945956    <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b> 
    946957               &lt;             &lt;             &lt;             &lt; 
    947 </pre><p id="rfc.section.2.3.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response 
     958</pre><p id="rfc.section.2.4.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response 
    948959         message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply 
    949960         only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along 
     
    952963         at the same time that it is handling A's request. 
    953964      </p> 
    954       <p id="rfc.section.2.3.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream. 
     965      <p id="rfc.section.2.4.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream. 
    955966         Likewise, we use the terms inbound and outbound to refer to directions in relation to the request path: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent. 
    956967      </p> 
    957       <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests 
     968      <p id="rfc.section.2.4.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests 
    958969         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations 
    959970         are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely 
     
    961972         for the sake of security, annotation services, or shared caching. 
    962973      </p> 
    963       <p id="rfc.section.2.3.p.6"> <span id="rfc.iref.t.1"></span>  <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications, 
     974      <p id="rfc.section.2.4.p.6"> <span id="rfc.iref.t.1"></span>  <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications, 
    964975         beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original 
    965976         sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared 
     
    969980         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 8.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 
    970981      </p> 
    971       <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying 
     982      <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying 
    972983         server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance 
    973984         through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. 
    974985      </p> 
    975       <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements 
     986      <p id="rfc.section.2.4.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements 
    976987         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 
    977988         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 
    978989         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>) header fields for both connections. 
    979990      </p> 
    980       <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party 
     991      <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party 
    981992         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both 
    982993         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 
    983994         when transport-layer security is used to establish private communication through a shared firewall proxy. 
    984995      </p> 
    985       <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless 
     996      <p id="rfc.section.2.4.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless 
    986997         act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a 
    987998         mess of things). Such a network intermediary, often referred to as an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "<dfn>captive portal</dfn>", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects 
     
    9921003      </p> 
    9931004      <div id="rfc.iref.c.4"></div> 
    994       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2> 
    995       <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. 
     1005      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2> 
     1006      <p id="rfc.section.2.5.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. 
    9961007         A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 
    9971008         requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel. 
    9981009      </p> 
    999       <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached 
     1010      <p id="rfc.section.2.5.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached 
    10001011         response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response 
    10011012         from O (via C) for a request which has not been cached by UA or A. 
     
    10041015       UA =========== A =========== B - - - - - - C - - - - - - O 
    10051016                  &lt;             &lt; 
    1006 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 
     1017</pre><p id="rfc.section.2.5.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 
    10071018         is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 
    10081019         can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 
    10091020      </p> 
    1010       <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and 
     1021      <p id="rfc.section.2.5.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and 
    10111022         inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems 
    10121023         that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so 
    10131024         on. 
    10141025      </p> 
    1015       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2> 
    1016       <p id="rfc.section.2.5.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". 
     1026      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2> 
     1027      <p id="rfc.section.2.6.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". 
    10171028         The protocol version as a whole indicates the sender's compliance with the set of requirements laid out in that version's 
    10181029         corresponding specification of HTTP. 
    10191030      </p> 
    1020       <p id="rfc.section.2.5.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 
     1031      <p id="rfc.section.2.6.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 
    10211032      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a> 
    10221033  <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive  
    1023 </pre><p id="rfc.section.2.5.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major 
     1034</pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major 
    10241035         version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version 
    10251036         to which the sender is at least conditionally compliant and able to understand for future communication. The minor version 
     
    10281039         requests (by clients). 
    10291040      </p> 
    1030       <p id="rfc.section.2.5.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 
     1041      <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 
    10311042         message if all of the newer features are ignored. This specification places recipient-version requirements on some new features 
    10321043         so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt 
    10331044         of a message, that the recipient supports HTTP/1.1. 
    10341045      </p> 
    1035       <p id="rfc.section.2.5.p.6">The interpretation of an HTTP header field does not change between minor versions of the same major version, though the default 
     1046      <p id="rfc.section.2.6.p.6">The interpretation of an HTTP header field does not change between minor versions of the same major version, though the default 
    10361047         behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 
    10371048         are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by 
    10381049         all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1. 
    10391050      </p> 
    1040       <p id="rfc.section.2.5.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation 
     1051      <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation 
    10411052         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received 
    10421053         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 
    10431054      </p> 
    1044       <p id="rfc.section.2.5.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary 
     1055      <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary 
    10451056         understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP 
    10461057         message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message 
    10471058         sender's version to determine what features are safe to use for later communication with that sender. 
    10481059      </p> 
    1049       <p id="rfc.section.2.5.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major 
     1060      <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major 
    10501061         version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. 
    10511062      </p> 
    1052       <p id="rfc.section.2.5.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after 
     1063      <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after 
    10531064         the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server) 
    10541065         that the server improperly handles higher request versions. 
    10551066      </p> 
    1056       <p id="rfc.section.2.5.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major 
     1067      <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major 
    10571068         version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's 
    10581069         request. 
    10591070      </p> 
    1060       <p id="rfc.section.2.5.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP 
     1071      <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP 
    10611072         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 
    10621073         number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the 
     
    10641075         User-Agent) uniquely match the values sent by a client known to be in error. 
    10651076      </p> 
    1066       <p id="rfc.section.2.5.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax 
     1077      <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax 
    10671078         is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 
    10681079         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented 
     
    10701081      </p> 
    10711082      <div id="rfc.iref.r.5"></div> 
    1072       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 
    1073       <p id="rfc.section.2.6.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects, 
     1083      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 
     1084      <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects, 
    10741085         and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to 
    10751086         interact with a resource via HTTP. More information on the scope of URIs and resources can be found in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. 
    10761087      </p> 
    1077       <p id="rfc.section.2.6.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", 
     1088      <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", 
    10781089         "path-absolute", "query", and "authority" from the URI generic syntax <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI but not a fragment. 
    10791090      </p> 
     
    10891100   
    10901101  <a href="#uri" class="smpl">partial-URI</a>   = relative-part [ "?" query ] 
    1091 </pre><p id="rfc.section.2.6.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows 
     1102</pre><p id="rfc.section.2.7.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows 
    10921103         any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, 
    10931104         or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request 
    10941105         URI, which defines the default base URI for references in both the request and its corresponding response. 
    10951106      </p> 
    1096       <h3 id="rfc.section.2.6.1"><a href="#rfc.section.2.6.1">2.6.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3> 
     1107      <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3> 
    10971108      <div id="rfc.iref.h.1"></div> 
    10981109      <div id="rfc.iref.u.3"></div> 
    1099       <p id="rfc.section.2.6.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical 
     1110      <p id="rfc.section.2.7.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical 
    11001111         namespace governed by a potential HTTP origin server listening for TCP connections on a given port. 
    11011112      </p> 
    11021113      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 
    1103 </pre><p id="rfc.section.2.6.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an 
     1114</pre><p id="rfc.section.2.7.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an 
    11041115         identifier for a potential resource within that origin server's name space. 
    11051116      </p> 
    1106       <p id="rfc.section.2.6.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated 
     1117      <p id="rfc.section.2.7.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated 
    11071118         TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient 
    11081119         might use a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved 
    11091120         port for WWW services). 
    11101121      </p> 
    1111       <p id="rfc.section.2.6.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address. 
     1122      <p id="rfc.section.2.7.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address. 
    11121123         The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening 
    11131124         to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish 
     
    11151126         authority to determine which names are valid and how they might be used. 
    11161127      </p> 
    1117       <p id="rfc.section.2.6.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 
     1128      <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 
    11181129         and sending an HTTP request message to the server containing the URI's identifying data as described in <a href="#request" title="Request">Section&nbsp;4</a>. If the server responds to that request with a non-interim HTTP response message, as described in <a href="#response" title="Response">Section&nbsp;5</a>, then that response is considered an authoritative answer to the client's request. 
    11191130      </p> 
    1120       <p id="rfc.section.2.6.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name 
     1131      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name 
    11211132         delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol 
    11221133         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require 
     
    11241135         — it is only the authoritative interface used for mapping the namespace that is specific to TCP. 
    11251136      </p> 
    1126       <p id="rfc.section.2.6.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal 
     1137      <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal 
    11271138         configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, 
    11281139         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> include a userinfo subcomponent (and its "@" delimiter) when transmitting an "http" URI in a message. Recipients of HTTP messages 
     
    11301141         is being used to obscure the authority for the sake of phishing attacks. 
    11311142      </p> 
    1132       <h3 id="rfc.section.2.6.2"><a href="#rfc.section.2.6.2">2.6.2</a>&nbsp;<a id="https.uri" href="#https.uri">https URI scheme</a></h3> 
     1143      <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;<a id="https.uri" href="#https.uri">https URI scheme</a></h3> 
    11331144      <div id="rfc.iref.h.2"></div> 
    11341145      <div id="rfc.iref.u.4"></div> 
    1135       <p id="rfc.section.2.6.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical 
     1146      <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical 
    11361147         namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. 
    11371148      </p> 
    1138       <p id="rfc.section.2.6.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default 
     1149      <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default 
    11391150         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request. 
    11401151      </p> 
    11411152      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 
    1142 </pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 
     1153</pre><p id="rfc.section.2.7.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 
    11431154         or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 
    11441155      </p> 
    1145       <p id="rfc.section.2.6.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers 
     1156      <p id="rfc.section.2.7.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers 
    11461157         indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered 
    11471158         to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the 
    11481159         Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains. 
    11491160      </p> 
    1150       <p id="rfc.section.2.6.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. 
    1151       </p> 
    1152       <h3 id="rfc.section.2.6.3"><a href="#rfc.section.2.6.3">2.6.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3> 
    1153       <p id="rfc.section.2.6.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to 
     1161      <p id="rfc.section.2.7.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. 
     1162      </p> 
     1163      <h3 id="rfc.section.2.7.3"><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3> 
     1164      <p id="rfc.section.2.7.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to 
    11541165         the algorithm defined in <a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-6">Section 6</a>, using the defaults described above for each scheme. 
    11551166      </p> 
    1156       <p id="rfc.section.2.6.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty 
     1167      <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty 
    11571168         path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme 
    11581169         and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. 
    11591170         Characters other than those in the "reserved" set are equivalent to their percent-encoded octets (see <a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>): the normal form is to not encode them. 
    11601171      </p> 
    1161       <p id="rfc.section.2.6.3.p.3">For example, the following three URIs are equivalent:</p> 
     1172      <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p> 
    11621173      <div id="rfc.figure.u.21"></div><pre class="text">   http://example.com:80/~smith/home.html 
    11631174   http://EXAMPLE.com/%7Esmith/home.html 
     
    14551466Host: www.example.org:8001 
    14561467</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>  
    1457       <p id="rfc.section.4.1.2.p.17">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 
     1468      <p id="rfc.section.4.1.2.p.17">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 
    14581469      </p> 
    14591470      <p id="rfc.section.4.1.2.p.18">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted 
     
    15331544         thus "https://www.example.org". 
    15341545      </p>  
    1535       <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 
     1546      <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 
    15361547      </p> 
    15371548      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1> 
     
    21852196         Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line. 
    21862197      </p> 
    2187       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.95"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a> 
     2198      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.95"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a> 
    21882199</pre><p id="rfc.section.9.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then 
    2189          the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 
     2200         the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 
    21902201      </p> 
    21912202      <p id="rfc.section.9.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p> 
     
    23192330      </p> 
    23202331      <p id="rfc.section.9.8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 
    2321          by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 
     2332         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 
    23222333         below. 
    23232334      </p> 
     
    24732484      <p id="rfc.section.10.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 
    24742485      <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> 
    2475       <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.6.1</a> and <a href="#https.uri" title="https URI scheme">2.6.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>). 
     2486      <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.7.1</a> and <a href="#https.uri" title="https URI scheme">2.7.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>). 
    24762487      </p> 
    24772488      <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2> 
     
    26512662                  <td class="left">HTTP</td> 
    26522663                  <td class="left">Hypertext Transfer Protocol</td> 
    2653                   <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a> of this specification 
     2664                  <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> of this specification 
    26542665                  </td> 
    26552666               </tr> 
     
    30503061      </p> 
    30513062      <p id="rfc.section.B.2.p.3">Clarify that the string "HTTP" in the HTTP-Version ABFN production is case sensitive. Restrict the version numbers to be single 
    3052          digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a>) 
     3063         digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a>) 
    30533064      </p> 
    30543065      <p id="rfc.section.B.2.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>) 
     
    35813592         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/273">http://tools.ietf.org/wg/httpbis/trac/ticket/273</a>&gt;: "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" 
    35823593         </li> 
     3594         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/283">http://tools.ietf.org/wg/httpbis/trac/ticket/283</a>&gt;: "Set expectations around buffering" 
     3595         </li> 
    35833596      </ul> 
    35843597      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 
     
    35893602            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 
    35903603                  <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">4.1.2</a></li> 
    3591                   <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li> 
     3604                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.4</b></a></li> 
    35923605                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>10.3.2</b></a></li> 
    35933606                  <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">4.1.2</a></li> 
     
    36013614            </li> 
    36023615            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 
    3603                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.4</b></a></li> 
    3604                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li> 
    3605                   <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li> 
     3616                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.5</b></a></li> 
     3617                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.5</b></a></li> 
     3618                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li> 
    36063619                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.2.1</a></li> 
    36073620                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li> 
     
    36163629                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li> 
    36173630                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li> 
    3618                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li> 
     3631                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li> 
    36193632                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 
    36203633               </ul> 
     
    36233636                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li> 
    36243637                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">6.2.2.2</a></li> 
    3625                   <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li> 
     3638                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.4</b></a></li> 
    36263639               </ul> 
    36273640            </li> 
     
    36313644            </li> 
    36323645            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 
    3633                   <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.3</b></a></li> 
     3646                  <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.4</b></a></li> 
    36343647                  <li><tt>Grammar</tt>&nbsp;&nbsp; 
    36353648                     <ul> 
    3636                         <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>2.6</b></a></li> 
     3649                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>2.7</b></a></li> 
    36373650                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li> 
    36383651                        <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>6.1</b></a></li> 
    36393652                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>6.2</b></a></li> 
    3640                         <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>2.6</b></a></li> 
     3653                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>2.7</b></a></li> 
    36413654                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 
    36423655                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>6.2.1</b></a></li> 
     
    36743687                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>6.1</b></a></li> 
    36753688                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>3</b></a></li> 
    3676                         <li><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>2.5</b></a></li> 
    3677                         <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>2.6.1</b></a></li> 
    3678                         <li><tt>HTTP-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.5</b></a></li> 
    3679                         <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>2.6.2</b></a></li> 
     3689                        <li><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>2.6</b></a></li> 
     3690                        <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>2.7.1</b></a></li> 
     3691                        <li><tt>HTTP-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.6</b></a></li> 
     3692                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>2.7.2</b></a></li> 
    36803693                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>6.2.1</b></a></li> 
    36813694                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li> 
     
    36883701                        <li>OCTET&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li> 
    36893702                        <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>1.2.2</b></a></li> 
    3690                         <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>2.6</b></a></li> 
    3691                         <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>2.6</b></a></li> 
     3703                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>2.7</b></a></li> 
     3704                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>2.7</b></a></li> 
    36923705                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>6.3</b></a></li> 
    36933706                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>6.3</b></a></li> 
     
    36973710                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>1.2.2</b></a></li> 
    36983711                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>6.2.1</b></a></li> 
    3699                         <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>2.6</b></a></li> 
     3712                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>2.7</b></a></li> 
    37003713                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2</b></a></li> 
    37013714                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>1.2.2</b></a></li> 
     
    37323745                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>6.2</b></a></li> 
    37333746                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.102"><b>9.8</b></a></li> 
    3734                         <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>2.6</b></a></li> 
    3735                         <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>2.6</b></a></li> 
     3747                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>2.7</b></a></li> 
     3748                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>2.7</b></a></li> 
    37363749                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>6.2</b></a></li> 
    37373750                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>1.2</b></a></li> 
     
    37493762                  <li>Header Fields&nbsp;&nbsp; 
    37503763                     <ul> 
    3751                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li> 
     3764                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li> 
    37523765                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 
    37533766                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li> 
     
    37573770                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 
    37583771                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li> 
    3759                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 
     3772                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 
    37603773                     </ul> 
    37613774                  </li> 
     
    37633776                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li> 
    37643777                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.iref.h.9"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3">B.1.1</a></li> 
    3765                   <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.6.1</b></a></li> 
    3766                   <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.6.2</a></li> 
     3778                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 
     3779                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li> 
    37673780               </ul> 
    37683781            </li> 
    37693782            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 
    3770                   <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.3</b></a></li> 
    3771                   <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.3</b></a></li> 
    3772                   <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.3</b></a></li> 
     3783                  <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.4</b></a></li> 
     3784                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.4</b></a></li> 
     3785                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.4</b></a></li> 
    37733786                  <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2</a>, <a href="#ISO-8859-1"><b>13.1</b></a></li> 
    37743787               </ul> 
     
    37913804            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 
    37923805                  <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">7.1.1</a>, <a href="#Nie1997"><b>13.2</b></a></li> 
    3793                   <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.3</b></a></li> 
     3806                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.4</b></a></li> 
    37943807               </ul> 
    37953808            </li> 
     
    37973810                  <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">4.1.2</a></li> 
    37983811                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li> 
    3799                   <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li> 
     3812                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.4</b></a></li> 
    38003813               </ul> 
    38013814            </li> 
    38023815            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 
    38033816                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li> 
    3804                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">5.1.1</a>, <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul> 
     3817                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">5.1.1</a>, <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul> 
    38053818                        <li><em>Section 7.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a></li> 
    38063819                        <li><em>Section 7.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4.1.2</a></li> 
     
    38083821                        <li><em>Section 8.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.2.3</a></li> 
    38093822                        <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">7.2.3</a></li> 
    3810                         <li><em>Section 8.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li> 
     3823                        <li><em>Section 8.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a></li> 
    38113824                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">9.8</a></li> 
    38123825                        <li><em>Section 8.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li> 
     
    38203833                     </ul> 
    38213834                  </li> 
    3822                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.6.2</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a>, <a href="#rfc.xref.Part6.6">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul> 
    3823                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li> 
     3835                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a>, <a href="#rfc.xref.Part6.6">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul> 
     3836                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.5</a></li> 
    38243837                        <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.3</a></li> 
    3825                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.6.2</a>, <a href="#rfc.xref.Part6.6">9.1</a></li> 
    3826                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li> 
     3838                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">9.1</a></li> 
     3839                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li> 
    38273840                     </ul> 
    38283841                  </li> 
    3829                   <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li> 
     3842                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.4</b></a></li> 
    38303843               </ul> 
    38313844            </li> 
     
    38333846                  <li>recipient&nbsp;&nbsp;<a href="#rfc.iref.r.1"><b>2.1</b></a></li> 
    38343847                  <li>request&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2.1</b></a></li> 
    3835                   <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.6</b></a></li> 
     3848                  <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.7</b></a></li> 
    38363849                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li> 
    3837                   <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.3</b></a></li> 
     3850                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.4</b></a></li> 
    38383851                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul> 
    38393852                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">6.1</a></li> 
     
    38413854                  </li> 
    38423855                  <li><em>RFC1900</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1900.1">11.4</a>, <a href="#RFC1900"><b>13.2</b></a></li> 
    3843                   <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>13.2</b></a></li> 
    3844                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.5</a>, <a href="#RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.2">B</a></li> 
     3856                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>13.2</b></a></li> 
     3857                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.2">B</a></li> 
    38453858                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1950.2">10.4</a>, <a href="#RFC1950"><b>13.1</b></a></li> 
    38463859                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1951.2">10.4</a>, <a href="#RFC1951"><b>13.1</b></a></li> 
     
    38513864                  </li> 
    38523865                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li> 
    3853                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2.5</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a><ul> 
     3866                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2.6</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a><ul> 
    38543867                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a></li> 
    38553868                     </ul> 
     
    38573870                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>13.1</b></a></li> 
    38583871                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">1</a>, <a href="#RFC2145"><b>13.2</b></a></li> 
    3859                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.5</a>, <a href="#rfc.xref.RFC2616.3">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.4">D.1</a></li> 
     3872                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.4">D.1</a></li> 
    38603873                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">B.2</a><ul> 
    38613874                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a></li> 
    38623875                     </ul> 
    38633876                  </li> 
    3864                   <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.6.2</a>, <a href="#RFC2818"><b>13.2</b></a></li> 
     3877                  <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>13.2</b></a></li> 
    38653878                  <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>13.2</b></a></li> 
    3866                   <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>13.2</b></a></li> 
     3879                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>13.2</b></a></li> 
    38673880                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">10.1</a>, <a href="#RFC3864"><b>13.2</b></a></li> 
    3868                   <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.6</a>, <a href="#rfc.xref.RFC3986.3">2.6</a>, <a href="#rfc.xref.RFC3986.4">2.6</a>, <a href="#rfc.xref.RFC3986.5">2.6</a>, <a href="#rfc.xref.RFC3986.6">2.6</a>, <a href="#rfc.xref.RFC3986.7">2.6</a>, <a href="#rfc.xref.RFC3986.8">2.6</a>, <a href="#rfc.xref.RFC3986.9">2.6</a>, <a href="#rfc.xref.RFC3986.10">2.6</a>, <a href="#rfc.xref.RFC3986.11">2.6</a>, <a href="#rfc.xref.RFC3986.12">2.6</a>, <a href="#rfc.xref.RFC3986.13">2.6</a>, <a href="#rfc.xref.RFC3986.14">2.6.1</a>, <a href="#rfc.xref.RFC3986.15">2.6.1</a>, <a href="#rfc.xref.RFC3986.16">2.6.3</a>, <a href="#rfc.xref.RFC3986.17">2.6.3</a>, <a href="#rfc.xref.RFC3986.18">4.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1.2</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>13.1</b></a><ul> 
    3869                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.6.3</a>, <a href="#rfc.xref.RFC3986.18">4.1.2</a></li> 
    3870                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.6</a></li> 
    3871                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.6.1</a></li> 
    3872                         <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.13">2.6</a>, <a href="#rfc.xref.RFC3986.14">2.6.1</a></li> 
    3873                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.11">2.6</a></li> 
    3874                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.9">2.6</a>, <a href="#rfc.xref.RFC3986.10">2.6</a></li> 
    3875                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.12">2.6</a></li> 
     3881                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">4.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1.2</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>13.1</b></a><ul> 
     3882                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">4.1.2</a></li> 
     3883                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li> 
     3884                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.7.1</a></li> 
     3885                        <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a></li> 
     3886                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.11">2.7</a></li> 
     3887                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a></li> 
     3888                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.12">2.7</a></li> 
    38763889                        <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.19">4.1.2</a></li> 
    3877                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.6</a></li> 
    3878                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.6</a></li> 
    3879                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.6</a>, <a href="#rfc.xref.RFC3986.20">4.3</a></li> 
    3880                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.6.3</a></li> 
     3890                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li> 
     3891                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li> 
     3892                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">4.3</a></li> 
     3893                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li> 
    38813894                     </ul> 
    38823895                  </li> 
     
    38973910                     </ul> 
    38983911                  </li> 
    3899                   <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.6.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>13.2</b></a></li> 
     3912                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>13.2</b></a></li> 
    39003913               </ul> 
    39013914            </li> 
     
    39133926                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">3.4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li> 
    39143927                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 
    3915                   <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li> 
    3916                   <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li> 
    3917                   <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.3</b></a></li> 
     3928                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.4</b></a></li> 
     3929                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.4</b></a></li> 
     3930                  <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.4</b></a></li> 
    39183931               </ul> 
    39193932            </li> 
    39203933            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 
    39213934                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li> 
    3922                   <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li> 
     3935                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li> 
    39233936                  <li>URI scheme&nbsp;&nbsp; 
    39243937                     <ul> 
    3925                         <li>http&nbsp;&nbsp;<a href="#rfc.iref.u.3"><b>2.6.1</b></a></li> 
    3926                         <li>https&nbsp;&nbsp;<a href="#rfc.iref.u.4">2.6.2</a></li> 
     3938                        <li>http&nbsp;&nbsp;<a href="#rfc.iref.u.3"><b>2.7.1</b></a></li> 
     3939                        <li>https&nbsp;&nbsp;<a href="#rfc.iref.u.4">2.7.2</a></li> 
    39273940                     </ul> 
    39283941                  </li> 
     
    39323945            </li> 
    39333946            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 
    3934                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 
     3947                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 
    39353948               </ul> 
    39363949            </li> 
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1313 r1316  
    620620<x:span anchor="exbody">Hello World! 
    621621</x:span></artwork></figure> 
     622</section> 
     623 
     624<section title="Message Orientation and Buffering" anchor="message-orientation-and-buffering"> 
     625<t> 
     626   Fundamentally, HTTP is a message-based protocol. Although message bodies can 
     627   be chunked (<xref target="chunked.encoding"/>) and implementations often 
     628   make parts of a message available progressively, this is not required, and 
     629   some widely-used implementations only make a message available when it is 
     630   complete. Furthermore, while most proxies will progressively stream messages, 
     631   some amount of buffering will take place, and some proxies might buffer 
     632   messages to perform transformations, check content or provide other services. 
     633</t> 
     634<t> 
     635   Therefore, extensions to and uses of HTTP cannot rely on the availability of 
     636   a partial message, or assume that messages will not be buffered. There are 
     637   strategies that can be used to test for buffering in a given connection, but 
     638   it should be understood that behaviors can differ across connections, and 
     639   between requests and responses.  
     640</t> 
    622641</section> 
    623642 
     
    58965915      "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" 
    58975916    </t> 
     5917    <t> 
     5918      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/283"/>: 
     5919      "Set expectations around buffering" 
     5920    </t> 
    58985921  </list> 
    58995922</t> 
Note: See TracChangeset for help on using the changeset viewer.