Source: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1316
Timestamp: 2014-09-17 17:32:29
Document Index: 399435971

Matched Legal Cases: ['art2', 'art2', 'art 2', 'art2', 'art6', 'art6', 'art 6', 'art6', 'arty 991', 'arty 981992', 'art6', 'art6', 'art 6', 'art6', 'art6', 'art6', 'art 6', 'art6', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6']

Changeset 1316 – httpbis
2011-06-29 02:14:48
set expectatiions around buffering (see #283)
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
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