![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1316 for draft-ietf-httpbis
- Timestamp:
- Jun 29, 2011, 2:14:48 AM (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p1-messaging.html (modified) (51 diffs)
-
p1-messaging.xml (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1313 r1316 359 359 } 360 360 @bottom-center { 361 content: "Expires December 29, 2011";361 content: "Expires December 31, 2011"; 362 362 } 363 363 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-06-2 7">412 <meta name="dct.issued" scheme="ISO8601" content="2011-06-29"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: December 29, 2011</td>444 <td class="left">Expires: December 31, 2011</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">June 2 7, 2011</td>497 <td class="right">June 29, 2011</td> 498 498 </tr> 499 499 </tbody> … … 525 525 in progress”. 526 526 </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> 528 528 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 529 529 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 554 554 <li>2. <a href="#architecture">HTTP-related architecture</a><ul> 555 555 <li>2.1 <a href="#operation">Client/Server Messaging</a></li> 556 <li>2.2 <a href="#transport-independence">Connections and Transport Independence</a></li> 557 <li>2.3 <a href="#intermediaries">Intermediaries</a></li> 558 <li>2.4 <a href="#caches">Caches</a></li> 559 <li>2.5 <a href="#http.version">Protocol Versioning</a></li> 560 <li>2.6 <a href="#uri">Uniform Resource Identifiers</a><ul> 561 <li>2.6.1 <a href="#http.uri">http URI scheme</a></li> 562 <li>2.6.2 <a href="#https.uri">https URI scheme</a></li> 563 <li>2.6.3 <a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 556 <li>2.2 <a href="#message-orientation-and-buffering">Message Orientation and Buffering</a></li> 557 <li>2.3 <a href="#transport-independence">Connections and Transport Independence</a></li> 558 <li>2.4 <a href="#intermediaries">Intermediaries</a></li> 559 <li>2.5 <a href="#caches">Caches</a></li> 560 <li>2.6 <a href="#http.version">Protocol Versioning</a></li> 561 <li>2.7 <a href="#uri">Uniform Resource Identifiers</a><ul> 562 <li>2.7.1 <a href="#http.uri">http URI scheme</a></li> 563 <li>2.7.2 <a href="#https.uri">https URI scheme</a></li> 564 <li>2.7.3 <a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 564 565 </ul> 565 566 </li> … … 925 926 926 927 <span id="exbody">Hello World! 927 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <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> <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 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> <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 929 940 transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request 930 941 and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. 931 942 </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's933 URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 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 use943 <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 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 934 945 a proxy via some other connection port or protocol instead of using the defaults. 935 946 </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 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 7.1</a>. 937 948 </p> 938 949 <div id="rfc.iref.i.1"></div> 939 <h2 id="rfc.section.2. 3"><a href="#rfc.section.2.3">2.3</a> <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 of950 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <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 941 952 HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, 942 953 switching behavior based on the nature of each request. … … 945 956 <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b> 946 957 < < < < 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 response958 </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 948 959 message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply 949 960 only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along … … 952 963 at the same time that it is handling A's request. 953 964 </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. 955 966 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. 956 967 </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 requests968 <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 958 969 for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations 959 970 are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely … … 961 972 for the sake of security, annotation services, or shared caching. 962 973 </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, 964 975 beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original 965 976 sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared … … 969 980 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. 970 981 </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 underlying982 <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 972 983 server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance 973 984 through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. 974 985 </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 requirements986 <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 976 987 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 977 988 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 978 989 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 9.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 9.9</a>) header fields for both connections. 979 990 </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 party991 <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 981 992 to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both 982 993 ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 983 994 when transport-layer security is used to establish private communication through a shared firewall proxy. 984 995 </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 nevertheless996 <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 986 997 act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a 987 998 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 … … 992 1003 </p> 993 1004 <div id="rfc.iref.c.4"></div> 994 <h2 id="rfc.section.2. 4"><a href="#rfc.section.2.4">2.4</a> <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> <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. 996 1007 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 997 1008 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. 998 1009 </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 cached1010 <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 1000 1011 response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response 1001 1012 from O (via C) for a request which has not been cached by UA or A. … … 1004 1015 UA =========== A =========== B - - - - - - C - - - - - - O 1005 1016 < < 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 response1017 </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 1007 1018 is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 1008 1019 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>. 1009 1020 </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 and1021 <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 1011 1022 inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems 1012 1023 that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so 1013 1024 on. 1014 1025 </p> 1015 <h2 id="rfc.section.2. 5"><a href="#rfc.section.2.5">2.5</a> <a id="http.version" href="#http.version">Protocol Versioning</a></h2>1016 <p id="rfc.section.2. 5.p.1">HTTP uses a "<major>.<minor>" 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> <a id="http.version" href="#http.version">Protocol Versioning</a></h2> 1027 <p id="rfc.section.2.6.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". 1017 1028 The protocol version as a whole indicates the sender's compliance with the set of requirements laid out in that version's 1018 1029 corresponding specification of HTTP. 1019 1030 </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> 1021 1032 <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> 1022 1033 <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 ("major1034 </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 1024 1035 version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version 1025 1036 to which the sender is at least conditionally compliant and able to understand for future communication. The minor version … … 1028 1039 requests (by clients). 1029 1040 </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.01041 <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 1031 1042 message if all of the newer features are ignored. This specification places recipient-version requirements on some new features 1032 1043 so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt 1033 1044 of a message, that the recipient supports HTTP/1.1. 1034 1045 </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 default1046 <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 1036 1047 behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 1037 1048 are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by 1038 1049 all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1. 1039 1050 </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 interpretation1051 <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 1041 1052 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 1042 1053 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 9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 1043 1054 </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 intermediary1055 <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 1045 1056 understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP 1046 1057 message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message 1047 1058 sender's version to determine what features are safe to use for later communication with that sender. 1048 1059 </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 major1060 <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 1050 1061 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. 1051 1062 </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 after1063 <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 1053 1064 the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server) 1054 1065 that the server improperly handles higher request versions. 1055 1066 </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 major1067 <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 1057 1068 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 1058 1069 request. 1059 1070 </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 HTTP1071 <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 1061 1072 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 1062 1073 number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the … … 1064 1075 User-Agent) uniquely match the values sent by a client known to be in error. 1065 1076 </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 syntax1077 <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 1067 1078 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1068 1079 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented … … 1070 1081 </p> 1071 1082 <div id="rfc.iref.r.5"></div> 1072 <h2 id="rfc.section.2. 6"><a href="#rfc.section.2.6">2.6</a> <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> <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, 1074 1085 and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to 1075 1086 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>. 1076 1087 </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", 1078 1089 "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. 1079 1090 </p> … … 1089 1100 1090 1101 <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 allows1102 </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 1092 1103 any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, 1093 1104 or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request 1094 1105 URI, which defines the default base URI for references in both the request and its corresponding response. 1095 1106 </p> 1096 <h3 id="rfc.section.2. 6.1"><a href="#rfc.section.2.6.1">2.6.1</a> <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> <a id="http.uri" href="#http.uri">http URI scheme</a></h3> 1097 1108 <div id="rfc.iref.h.1"></div> 1098 1109 <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 hierarchical1110 <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 1100 1111 namespace governed by a potential HTTP origin server listening for TCP connections on a given port. 1101 1112 </p> 1102 1113 <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 an1114 </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 1104 1115 identifier for a potential resource within that origin server's name space. 1105 1116 </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 indicated1117 <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 1107 1118 TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient 1108 1119 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 1109 1120 port for WWW services). 1110 1121 </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. 1112 1123 The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening 1113 1124 to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish … … 1115 1126 authority to determine which names are valid and how they might be used. 1116 1127 </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, 1118 1129 and sending an HTTP request message to the server containing the URI's identifying data as described in <a href="#request" title="Request">Section 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 5</a>, then that response is considered an authoritative answer to the client's request. 1119 1130 </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 name1131 <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 1121 1132 delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol 1122 1133 would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require … … 1124 1135 — it is only the authoritative interface used for mapping the namespace that is specific to TCP. 1125 1136 </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 internal1137 <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 1127 1138 configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, 1128 1139 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 … … 1130 1141 is being used to obscure the authority for the sake of phishing attacks. 1131 1142 </p> 1132 <h3 id="rfc.section.2. 6.2"><a href="#rfc.section.2.6.2">2.6.2</a> <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> <a id="https.uri" href="#https.uri">https URI scheme</a></h3> 1133 1144 <div id="rfc.iref.h.2"></div> 1134 1145 <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 hierarchical1146 <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 1136 1147 namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. 1137 1148 </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 default1149 <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 1139 1150 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. 1140 1151 </p> 1141 1152 <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 HTTP1153 </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 1143 1154 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>). 1144 1155 </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 identifiers1156 <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 1146 1157 indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered 1147 1158 to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the 1148 1159 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. 1149 1160 </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> <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 to1161 <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> <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 1154 1165 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. 1155 1166 </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 empty1167 <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 1157 1168 path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme 1158 1169 and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. 1159 1170 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. 1160 1171 </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> 1162 1173 <div id="rfc.figure.u.21"></div><pre class="text"> http://example.com:80/~smith/home.html 1163 1174 http://EXAMPLE.com/%7Esmith/home.html … … 1455 1466 Host: www.example.org:8001 1456 1467 </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 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 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. 1458 1469 </p> 1459 1470 <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 … … 1533 1544 thus "https://www.example.org". 1534 1545 </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 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 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 1536 1547 </p> 1537 1548 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1> … … 2185 2196 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. 2186 2197 </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 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 2.7.1</a> 2188 2199 </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 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 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. 2190 2201 </p> 2191 2202 <p id="rfc.section.9.4.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> … … 2319 2330 </p> 2320 2331 <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 2. 5</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined2332 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2322 2333 below. 2323 2334 </p> … … 2473 2484 <p id="rfc.section.10.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2474 2485 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <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 <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> 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 <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> 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>). 2476 2487 </p> 2477 2488 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2> … … 2651 2662 <td class="left">HTTP</td> 2652 2663 <td class="left">Hypertext Transfer Protocol</td> 2653 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2. 5</a> of this specification2664 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2.6</a> of this specification 2654 2665 </td> 2655 2666 </tr> … … 3050 3061 </p> 3051 3062 <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 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 2.6</a>) 3053 3064 </p> 3054 3065 <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 3.2</a>) … … 3581 3592 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/273">http://tools.ietf.org/wg/httpbis/trac/ticket/273</a>>: "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" 3582 3593 </li> 3594 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/283">http://tools.ietf.org/wg/httpbis/trac/ticket/283</a>>: "Set expectations around buffering" 3595 </li> 3583 3596 </ul> 3584 3597 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> … … 3589 3602 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3590 3603 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.3">4.1.2</a></li> 3591 <li>accelerator <a href="#rfc.iref.a.1"><b>2. 3</b></a></li>3604 <li>accelerator <a href="#rfc.iref.a.1"><b>2.4</b></a></li> 3592 3605 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>10.3.2</b></a></li> 3593 3606 <li>asterisk form (of request-target) <a href="#rfc.iref.a.2">4.1.2</a></li> … … 3601 3614 </li> 3602 3615 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3603 <li>cache <a href="#rfc.iref.c.4"><b>2. 4</b></a></li>3604 <li>cacheable <a href="#rfc.iref.c.5"><b>2. 4</b></a></li>3605 <li>captive portal <a href="#rfc.iref.c.3"><b>2. 3</b></a></li>3616 <li>cache <a href="#rfc.iref.c.4"><b>2.5</b></a></li> 3617 <li>cacheable <a href="#rfc.iref.c.5"><b>2.5</b></a></li> 3618 <li>captive portal <a href="#rfc.iref.c.3"><b>2.4</b></a></li> 3606 3619 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">6.2.1</a></li> 3607 3620 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> … … 3616 3629 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3617 3630 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3618 <li>Connection header field <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 <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> 3619 3632 <li>Content-Length header field <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> 3620 3633 </ul> … … 3623 3636 <li>Date header field <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> 3624 3637 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.2.2.2</a></li> 3625 <li>downstream <a href="#rfc.iref.d.1"><b>2. 3</b></a></li>3638 <li>downstream <a href="#rfc.iref.d.1"><b>2.4</b></a></li> 3626 3639 </ul> 3627 3640 </li> … … 3631 3644 </li> 3632 3645 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3633 <li>gateway <a href="#rfc.iref.g.24"><b>2. 3</b></a></li>3646 <li>gateway <a href="#rfc.iref.g.24"><b>2.4</b></a></li> 3634 3647 <li><tt>Grammar</tt> 3635 3648 <ul> 3636 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.28"><b>2. 6</b></a></li>3649 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.28"><b>2.7</b></a></li> 3637 3650 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3638 3651 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.68"><b>6.1</b></a></li> 3639 3652 <li><tt>attribute</tt> <a href="#rfc.iref.g.72"><b>6.2</b></a></li> 3640 <li><tt>authority</tt> <a href="#rfc.iref.g.29"><b>2. 6</b></a></li>3653 <li><tt>authority</tt> <a href="#rfc.iref.g.29"><b>2.7</b></a></li> 3641 3654 <li><tt>BWS</tt> <a href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 3642 3655 <li><tt>chunk</tt> <a href="#rfc.iref.g.77"><b>6.2.1</b></a></li> … … 3674 3687 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.53"><b>6.1</b></a></li> 3675 3688 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.36"><b>3</b></a></li> 3676 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g.26"><b>2. 5</b></a></li>3677 <li><tt>http-URI</tt> <a href="#rfc.iref.g.34"><b>2. 6.1</b></a></li>3678 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.25"><b>2. 5</b></a></li>3679 <li><tt>https-URI</tt> <a href="#rfc.iref.g.35"><b>2. 6.2</b></a></li>3689 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g.26"><b>2.6</b></a></li> 3690 <li><tt>http-URI</tt> <a href="#rfc.iref.g.34"><b>2.7.1</b></a></li> 3691 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.25"><b>2.6</b></a></li> 3692 <li><tt>https-URI</tt> <a href="#rfc.iref.g.35"><b>2.7.2</b></a></li> 3680 3693 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.79"><b>6.2.1</b></a></li> 3681 3694 <li>LF <a href="#rfc.iref.g.8"><b>1.2</b></a></li> … … 3688 3701 <li>OCTET <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3689 3702 <li><tt>OWS</tt> <a href="#rfc.iref.g.13"><b>1.2.2</b></a></li> 3690 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.30"><b>2. 6</b></a></li>3691 <li><tt>port</tt> <a href="#rfc.iref.g.31"><b>2. 6</b></a></li>3703 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.30"><b>2.7</b></a></li> 3704 <li><tt>port</tt> <a href="#rfc.iref.g.31"><b>2.7</b></a></li> 3692 3705 <li><tt>product</tt> <a href="#rfc.iref.g.88"><b>6.3</b></a></li> 3693 3706 <li><tt>product-version</tt> <a href="#rfc.iref.g.89"><b>6.3</b></a></li> … … 3697 3710 <li><tt>qdtext</tt> <a href="#rfc.iref.g.21"><b>1.2.2</b></a></li> 3698 3711 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.86"><b>6.2.1</b></a></li> 3699 <li><tt>query</tt> <a href="#rfc.iref.g.32"><b>2. 6</b></a></li>3712 <li><tt>query</tt> <a href="#rfc.iref.g.32"><b>2.7</b></a></li> 3700 3713 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.43"><b>3.2</b></a></li> 3701 3714 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.23"><b>1.2.2</b></a></li> … … 3732 3745 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.71"><b>6.2</b></a></li> 3733 3746 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.102"><b>9.8</b></a></li> 3734 <li><tt>uri-host</tt> <a href="#rfc.iref.g.33"><b>2. 6</b></a></li>3735 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.27"><b>2. 6</b></a></li>3747 <li><tt>uri-host</tt> <a href="#rfc.iref.g.33"><b>2.7</b></a></li> 3748 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.27"><b>2.7</b></a></li> 3736 3749 <li><tt>value</tt> <a href="#rfc.iref.g.73"><b>6.2</b></a></li> 3737 3750 <li>VCHAR <a href="#rfc.iref.g.11"><b>1.2</b></a></li> … … 3749 3762 <li>Header Fields 3750 3763 <ul> 3751 <li>Connection <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 <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> 3752 3765 <li>Content-Length <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> 3753 3766 <li>Date <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> … … 3757 3770 <li>Transfer-Encoding <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> 3758 3771 <li>Upgrade <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 <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 <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> 3760 3773 </ul> 3761 3774 </li> … … 3763 3776 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3764 3777 <li>Host header field <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 <a href="#rfc.iref.h.1"><b>2. 6.1</b></a></li>3766 <li>https URI scheme <a href="#rfc.iref.h.2">2. 6.2</a></li>3778 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3779 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> 3767 3780 </ul> 3768 3781 </li> 3769 3782 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 3770 <li>inbound <a href="#rfc.iref.i.2"><b>2. 3</b></a></li>3771 <li>interception proxy <a href="#rfc.iref.i.3"><b>2. 3</b></a></li>3772 <li>intermediary <a href="#rfc.iref.i.1"><b>2. 3</b></a></li>3783 <li>inbound <a href="#rfc.iref.i.2"><b>2.4</b></a></li> 3784 <li>interception proxy <a href="#rfc.iref.i.3"><b>2.4</b></a></li> 3785 <li>intermediary <a href="#rfc.iref.i.1"><b>2.4</b></a></li> 3773 3786 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2</a>, <a href="#ISO-8859-1"><b>13.1</b></a></li> 3774 3787 </ul> … … 3791 3804 <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 3792 3805 <li><em>Nie1997</em> <a href="#rfc.xref.Nie1997.1">7.1.1</a>, <a href="#Nie1997"><b>13.2</b></a></li> 3793 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2. 3</b></a></li>3806 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2.4</b></a></li> 3794 3807 </ul> 3795 3808 </li> … … 3797 3810 <li>origin form (of request-target) <a href="#rfc.iref.o.3">4.1.2</a></li> 3798 3811 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3799 <li>outbound <a href="#rfc.iref.o.2"><b>2. 3</b></a></li>3812 <li>outbound <a href="#rfc.iref.o.2"><b>2.4</b></a></li> 3800 3813 </ul> 3801 3814 </li> 3802 3815 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3803 3816 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li> 3804 <li><em>Part2</em> <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> <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> 3805 3818 <li><em>Section 7.1.2</em> <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a></li> 3806 3819 <li><em>Section 7.9</em> <a href="#rfc.xref.Part2.2">4.1.2</a></li> … … 3808 3821 <li><em>Section 8.1.1</em> <a href="#rfc.xref.Part2.7">7.2.3</a></li> 3809 3822 <li><em>Section 8.1</em> <a href="#rfc.xref.Part2.10">7.2.3</a></li> 3810 <li><em>Section 8.2.4</em> <a href="#rfc.xref.Part2.1">2. 3</a></li>3823 <li><em>Section 8.2.4</em> <a href="#rfc.xref.Part2.1">2.4</a></li> 3811 3824 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.11">9.8</a></li> 3812 3825 <li><em>Section 8.4.15</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li> … … 3820 3833 </ul> 3821 3834 </li> 3822 <li><em>Part6</em> <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> <a href="#rfc.xref.Part6.2">2. 4</a></li>3835 <li><em>Part6</em> <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> <a href="#rfc.xref.Part6.2">2.5</a></li> 3824 3837 <li><em>Section 2.1.1</em> <a href="#rfc.xref.Part6.4">3.3</a></li> 3825 <li><em>Section 3.2</em> <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> <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> <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> <a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li> 3827 3840 </ul> 3828 3841 </li> 3829 <li>proxy <a href="#rfc.iref.p.1"><b>2. 3</b></a></li>3842 <li>proxy <a href="#rfc.iref.p.1"><b>2.4</b></a></li> 3830 3843 </ul> 3831 3844 </li> … … 3833 3846 <li>recipient <a href="#rfc.iref.r.1"><b>2.1</b></a></li> 3834 3847 <li>request <a href="#rfc.iref.r.2"><b>2.1</b></a></li> 3835 <li>resource <a href="#rfc.iref.r.5"><b>2. 6</b></a></li>3848 <li>resource <a href="#rfc.iref.r.5"><b>2.7</b></a></li> 3836 3849 <li>response <a href="#rfc.iref.r.3"><b>2.1</b></a></li> 3837 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2. 3</b></a></li>3850 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2.4</b></a></li> 3838 3851 <li><em>RFC1123</em> <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> 3839 3852 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">6.1</a></li> … … 3841 3854 </li> 3842 3855 <li><em>RFC1900</em> <a href="#rfc.xref.RFC1900.1">11.4</a>, <a href="#RFC1900"><b>13.2</b></a></li> 3843 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2. 3</a>, <a href="#RFC1919"><b>13.2</b></a></li>3844 <li><em>RFC1945</em> <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> <a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>13.2</b></a></li> 3857 <li><em>RFC1945</em> <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> 3845 3858 <li><em>RFC1950</em> <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> 3846 3859 <li><em>RFC1951</em> <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> … … 3851 3864 </li> 3852 3865 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li> 3853 <li><em>RFC2068</em> <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> <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> 3854 3867 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a></li> 3855 3868 </ul> … … 3857 3870 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>13.1</b></a></li> 3858 3871 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#RFC2145"><b>13.2</b></a></li> 3859 <li><em>RFC2616</em> <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> <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> 3860 3873 <li><em>RFC2817</em> <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> 3861 3874 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.1">10.5</a></li> 3862 3875 </ul> 3863 3876 </li> 3864 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2. 6.2</a>, <a href="#RFC2818"><b>13.2</b></a></li>3877 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>13.2</b></a></li> 3865 3878 <li><em>RFC2965</em> <a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>13.2</b></a></li> 3866 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2. 3</a>, <a href="#RFC3040"><b>13.2</b></a></li>3879 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>13.2</b></a></li> 3867 3880 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">10.1</a>, <a href="#RFC3864"><b>13.2</b></a></li> 3868 <li><em>RFC3986</em> <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> <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> <a href="#rfc.xref.RFC3986.8">2. 6</a></li>3871 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2. 6.1</a></li>3872 <li><em>Section 3.2.2</em> <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> <a href="#rfc.xref.RFC3986.11">2. 6</a></li>3874 <li><em>Section 3.3</em> <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> <a href="#rfc.xref.RFC3986.12">2. 6</a></li>3881 <li><em>RFC3986</em> <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> <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> <a href="#rfc.xref.RFC3986.8">2.7</a></li> 3884 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2.7.1</a></li> 3885 <li><em>Section 3.2.2</em> <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> <a href="#rfc.xref.RFC3986.11">2.7</a></li> 3887 <li><em>Section 3.3</em> <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> <a href="#rfc.xref.RFC3986.12">2.7</a></li> 3876 3889 <li><em>Section 3.5</em> <a href="#rfc.xref.RFC3986.19">4.1.2</a></li> 3877 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2. 6</a></li>3878 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2. 6</a></li>3879 <li><em>Section 4.3</em> <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> <a href="#rfc.xref.RFC3986.16">2. 6.3</a></li>3890 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3891 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</a></li> 3892 <li><em>Section 4.3</em> <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> <a href="#rfc.xref.RFC3986.16">2.7.3</a></li> 3881 3894 </ul> 3882 3895 </li> … … 3897 3910 </ul> 3898 3911 </li> 3899 <li><em>RFC6265</em> <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> <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> 3900 3913 </ul> 3901 3914 </li> … … 3913 3926 <li>Trailer header field <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> 3914 3927 <li>Transfer-Encoding header field <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 <a href="#rfc.iref.t.1"><b>2. 3</b></a></li>3916 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2. 3</b></a></li>3917 <li>tunnel <a href="#rfc.iref.t.2"><b>2. 3</b></a></li>3928 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.4</b></a></li> 3929 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.4</b></a></li> 3930 <li>tunnel <a href="#rfc.iref.t.2"><b>2.4</b></a></li> 3918 3931 </ul> 3919 3932 </li> 3920 3933 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3921 3934 <li>Upgrade header field <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 <a href="#rfc.iref.u.2"><b>2. 3</b></a></li>3935 <li>upstream <a href="#rfc.iref.u.2"><b>2.4</b></a></li> 3923 3936 <li>URI scheme 3924 3937 <ul> 3925 <li>http <a href="#rfc.iref.u.3"><b>2. 6.1</b></a></li>3926 <li>https <a href="#rfc.iref.u.4">2. 6.2</a></li>3938 <li>http <a href="#rfc.iref.u.3"><b>2.7.1</b></a></li> 3939 <li>https <a href="#rfc.iref.u.4">2.7.2</a></li> 3927 3940 </ul> 3928 3941 </li> … … 3932 3945 </li> 3933 3946 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3934 <li>Via header field <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 <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> 3935 3948 </ul> 3936 3949 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1313 r1316 620 620 <x:span anchor="exbody">Hello World! 621 621 </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> 622 641 </section> 623 642 … … 5896 5915 "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" 5897 5916 </t> 5917 <t> 5918 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/283"/>: 5919 "Set expectations around buffering" 5920 </t> 5898 5921 </list> 5899 5922 </t>
Note: See TracChangeset
for help on using the changeset viewer.
