Changeset 1149 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 05/03/11 10:54:54 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1145 r1149 359 359 } 360 360 @bottom-center { 361 content: "Expires September 2, 2011";361 content: "Expires September 6, 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-03-01"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-03-05"> 413 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 413 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 414 415 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 427 428 </tr> 428 429 <tr> 429 <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2 616">2616</a> (if approved)430 <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2145">2145</a>, <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved) 430 431 </td> 431 432 <td class="right">J. Gettys</td> … … 441 442 </tr> 442 443 <tr> 443 <td class="left">Expires: September 2, 2011</td>444 <td class="left">Expires: September 6, 2011</td> 444 445 <td class="right">HP</td> 445 446 </tr> … … 494 495 <tr> 495 496 <td class="left"></td> 496 <td class="right">March 1, 2011</td>497 <td class="right">March 5, 2011</td> 497 498 </tr> 498 499 </tbody> … … 522 523 in progress”. 523 524 </p> 524 <p>This Internet-Draft will expire on September 2, 2011.</p>525 <p>This Internet-Draft will expire on September 6, 2011.</p> 525 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 526 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 552 553 <li>2. <a href="#architecture">HTTP-related architecture</a><ul> 553 554 <li>2.1 <a href="#operation">Client/Server Messaging</a></li> 554 <li>2.2 <a href="# intermediaries">Intermediaries</a></li>555 <li>2.3 <a href="# caches">Caches</a></li>556 <li>2.4 <a href="# transport-independence">Transport Independence</a></li>557 <li>2.5 <a href="#http.version"> HTTP Version</a></li>555 <li>2.2 <a href="#transport-independence">Connections and Transport Independence</a></li> 556 <li>2.3 <a href="#intermediaries">Intermediaries</a></li> 557 <li>2.4 <a href="#caches">Caches</a></li> 558 <li>2.5 <a href="#http.version">Protocol Versioning</a></li> 558 559 <li>2.6 <a href="#uri">Uniform Resource Identifiers</a><ul> 559 560 <li>2.6.1 <a href="#http.uri">http URI scheme</a></li> … … 736 737 at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. 737 738 </p> 738 <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes,739 <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, 739 740 describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. 740 741 Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, … … 930 931 931 932 <span id="exbody">Hello World! 932 </span></pre><div id="rfc.iref.i.1"></div> 933 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 934 <p id="rfc.section.2.2.p.1">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three 935 common forms of intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, 936 proxy, gateway, or tunnel, switching behavior based on the nature of each request. 933 </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> 934 <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 935 transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request 936 and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. 937 </p> 938 <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 identifier 939 (if any) provided for the request target. 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 use 940 a proxy via some other connection port or protocol instead of using the defaults. 941 </p> 942 <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>. 943 </p> 944 <div id="rfc.iref.i.1"></div> 945 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 946 <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 947 HTTP intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, 948 gateway, or tunnel, switching behavior based on the nature of each request. 937 949 </p> 938 950 <div id="rfc.figure.u.18"></div><pre class="drawing"> > > > > 939 951 UA =========== A =========== B =========== C =========== O 940 952 < < < < 941 </pre><p id="rfc.section.2. 2.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response953 </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 942 954 message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply 943 955 only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along … … 946 958 at the same time that it is handling A's request. 947 959 </p> 948 <p id="rfc.section.2. 2.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 "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:960 <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 "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message: 949 961 all messages flow from upstream to downstream. Likewise, we use the terms "inbound" and "outbound" to refer to directions 950 962 in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent. 951 963 </p> 952 <p id="rfc.section.2. 2.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive964 <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive 953 965 requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. 954 966 Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation … … 956 968 through a common intermediary for the sake of security, annotation services, or shared caching. 957 969 </p> 958 <p id="rfc.section.2. 2.p.6"> <span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify request or response messages970 <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 "transforming proxy" if it is designed or configured to modify request or response messages 959 971 in a semantically meaningful way (i.e., modifications, beyond those required by normal HTTP processing, that change the message 960 972 in a way that would be significant to the original sender or potentially significant to downstream recipients). For example, … … 965 977 that preserve HTTP message semantics. 966 978 </p> 967 <p id="rfc.section.2. 2.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates979 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates 968 980 the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP 969 981 services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the target … … 973 985 the scope of this specification. 974 986 </p> 975 <p id="rfc.section.2. 2.p.8"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered987 <p id="rfc.section.2.3.p.8"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered 976 988 a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist 977 989 when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, 978 990 such as when transport-layer security is used to establish private communication through a shared firewall proxy. 979 991 </p> 980 <p id="rfc.section.2. 2.p.9"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless992 <p id="rfc.section.2.3.p.9"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless 981 993 act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a 982 994 mess of things). Such a network intermediary, referred to as an "interception proxy" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> or "transparent proxy" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects outgoing … … 986 998 </p> 987 999 <div id="rfc.iref.c.3"></div> 988 <h2 id="rfc.section.2. 3"><a href="#rfc.section.2.3">2.3</a> <a id="caches" href="#caches">Caches</a></h2>989 <p id="rfc.section.2. 3.p.1">A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and1000 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="caches" href="#caches">Caches</a></h2> 1001 <p id="rfc.section.2.4.p.1">A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and 990 1002 deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, 991 1003 equivalent 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. 992 1004 </p> 993 <p id="rfc.section.2. 3.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 cached1005 <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 994 1006 response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response 995 1007 from O (via C) for a request which has not been cached by UA or A. … … 998 1010 UA =========== A =========== B - - - - - - C - - - - - - O 999 1011 < < 1000 </pre><p id="rfc.section.2. 3.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.1012 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 1001 1013 Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when 1002 1014 that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are 1003 1015 defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1004 1016 </p> 1005 <p id="rfc.section.2. 3.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and1017 <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 1006 1018 inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems 1007 1019 that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so 1008 1020 on. 1009 1021 </p> 1010 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="transport-independence" href="#transport-independence">Transport Independence</a></h2> 1011 <p id="rfc.section.2.4.p.1">HTTP systems are used in a wide variety of environments, from corporate intranets with high-bandwidth links to long-distance 1012 communication over low-power radio links and intermittent connectivity. 1013 </p> 1014 <p id="rfc.section.2.4.p.2">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (<<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>>), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, 1015 or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the 1016 mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside 1017 the scope of this specification. 1018 </p> 1019 <p id="rfc.section.2.4.p.3">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection might 1020 be used for one or more request/response exchanges, although connections might be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>). 1021 </p> 1022 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="http.version" href="#http.version">HTTP Version</a></h2> 1023 <p id="rfc.section.2.5.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended 1024 to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather 1025 than the features obtained via that communication. No change is made to the version number for the addition of message components 1026 which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented 1027 when the changes made to the protocol add features which do not change the general message parsing algorithm, but which might 1028 add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format 1029 of a message within the protocol is changed. See <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation. 1022 <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> 1023 <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". 1024 The protocol version as a whole indicates the sender's compliance with the set of requirements laid out in that version's 1025 corresponding specification of HTTP. 1030 1026 </p> 1031 1027 <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> 1032 1028 <div id="rfc.figure.u.20"></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> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a> 1033 1029 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 1034 </pre><p id="rfc.section.2.5.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. 1035 Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent. 1036 </p> 1037 <p id="rfc.section.2.5.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this 1038 specification <em class="bcp14">SHOULD</em> use an HTTP-Version of "HTTP/1.1" in their messages, and <em class="bcp14">MUST</em> do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, 1039 see <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. 1040 </p> 1041 <p id="rfc.section.2.5.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p> 1042 <p id="rfc.section.2.5.p.7">Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the 1043 application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway <em class="bcp14">MUST NOT</em> send a message with a version indicator which is greater than its actual version. If a higher version request is received, 1044 the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior. 1045 </p> 1046 <p id="rfc.section.2.5.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request. 1047 </p> 1048 <div class="note" id="rfc.section.2.5.p.9"> 1049 <p> <b>Note:</b> Converting between versions of HTTP might involve modification of header fields required or forbidden by the versions involved. 1050 </p> 1051 </div> 1030 </pre><p id="rfc.section.2.5.p.4">The HTTP version number consists of two non-negative decimal integers separated by the "." (period or decimal point) character. 1031 The first number ("major version") indicates the HTTP messaging syntax, whereas the second number ("minor version") indicates 1032 the highest minor version to which the sender is at least conditionally compliant and able to understand for future communication. 1033 The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible 1034 subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) 1035 or in future requests (by clients). 1036 </p> 1037 <p id="rfc.section.2.5.p.5">When comparing HTTP versions, the numbers <em class="bcp14">MUST</em> be compared numerically rather than lexically. For example, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower 1038 than HTTP/12.3. Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent. 1039 </p> 1040 <p id="rfc.section.2.5.p.6">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient (or a recipient whose version is unknown), the HTTP/1.1 message 1041 is constructed such that it will be interpreted as a valid HTTP/1.0 message even if all of the provided header fields not 1042 defined in the HTTP/1.0 specification <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> are ignored. This specification excludes incompatible message constructions by imposing recipient-version requirements on 1043 new HTTP/1.1 features that are not safely interpreted by earlier HTTP/1.0 recipients. 1044 </p> 1045 <p id="rfc.section.2.5.p.7">The interpretation of an HTTP message header field does not change between minor versions of the same major version, though 1046 the default behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined 1047 in HTTP/1.1 are defined for all versions of HTTP/1.x. The most popular example of this is the Host header field, which was 1048 introduced during the standardization process of HTTP/1.1 and widely deployed for HTTP/1.0 requests out of necessity. 1049 </p> 1050 <p id="rfc.section.2.5.p.8">Likewise, new header fields can be defined such that, when they are understood by a recipient, they might override or enhance 1051 the interpretation of previously defined header fields. When an implementation receives an unrecognized header field, the 1052 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 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.1" title="Connection">Section 9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 1054 </p> 1055 <p id="rfc.section.2.5.p.9">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 1056 understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP 1057 message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message 1058 sender's version to determine what features are safe to use for later communication with that sender. 1059 </p> 1060 <p id="rfc.section.2.5.p.10">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 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. 1062 </p> 1063 <p id="rfc.section.2.5.p.11">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 1064 the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server) 1065 that the server improperly handles higher request versions. 1066 </p> 1067 <p id="rfc.section.2.5.p.12">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 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 1069 request. 1070 </p> 1071 <p id="rfc.section.2.5.p.13">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 1072 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 1073 number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the 1074 given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., 1075 User-Agent) uniquely match the values sent by a client known to be in error. 1076 </p> 1077 <p id="rfc.section.2.5.p.14">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax 1078 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1079 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented 1080 for the changes introduced in <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol. 1081 </p> 1052 1082 <div id="rfc.iref.r.4"></div> 1053 1083 <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> … … 1337 1367 <tr> 1338 1368 <td class="left">Connection</td> 1339 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection. 1" title="Connection">Section 9.1</a></td>1369 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 9.1</a></td> 1340 1370 </tr> 1341 1371 <tr> … … 1828 1858 </p> 1829 1859 <p id="rfc.section.7.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 1830 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 2" title="Connection">Section 9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.1860 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 1831 1861 </p> 1832 1862 <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> … … 1854 1884 </p> 1855 1885 <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3> 1856 <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection. 3" title="Connection">Section 9.1</a>.1886 <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 9.1</a>. 1857 1887 </p> 1858 1888 <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects 1859 1889 to. Each persistent connection applies to only one transport link. 1860 1890 </p> 1861 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068. 2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).1891 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 1862 1892 </p> 1863 1893 <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a> <a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4> … … 1883 1913 </ul> 1884 1914 <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> 1885 <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 4" title="Connection">Section 9.1</a>).1915 <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 9.1</a>). 1886 1916 </p> 1887 1917 <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4> … … 1985 2015 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" 1986 2016 expectation, and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this 1987 rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068. 3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header2017 rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header 1988 2018 field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays 1989 2019 associated with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests … … 2191 2221 TE: 2192 2222 TE: trailers, deflate;q=0.5 2193 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 5" title="Connection">Section 9.1</a>) whenever TE is present in an HTTP/1.1 message.2223 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 9.1</a>) whenever TE is present in an HTTP/1.1 message. 2194 2224 </p> 2195 2225 <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> … … 2277 2307 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2278 2308 </p> 2279 <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 6" title="Connection">Section 9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2309 <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 9.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2280 2310 </p> 2281 2311 <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it … … 2286 2316 </p> 2287 2317 <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 2288 by the HTTP version rules of <a href="#http.version" title=" HTTP Version">Section 2.5</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined2318 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 defined 2289 2319 below. 2290 2320 </p> … … 2375 2405 <td class="left">http</td> 2376 2406 <td class="left">standard</td> 2377 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection. 7" title="Connection">Section 9.1</a>2407 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 9.1</a> 2378 2408 </td> 2379 2409 </tr> … … 2617 2647 <td class="left">HTTP</td> 2618 2648 <td class="left">Hypertext Transfer Protocol</td> 2619 <td class="left"><a href="#http.version" title=" HTTP Version">Section 2.5</a> of this specification2649 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2.5</a> of this specification 2620 2650 </td> 2621 2651 </tr> … … 2709 2739 </p> 2710 2740 <p id="rfc.section.12.p.4">Thanks to the "cave men" of Palo Alto. You know who you are.</p> 2711 <p id="rfc.section.12.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616. 2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott2741 <p id="rfc.section.12.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott 2712 2742 Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the 2713 2743 "MUST/MAY/SHOULD" audit. … … 2746 2776 <td class="reference"><b id="RFC1950">[RFC1950]</b></td> 2747 2777 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996.<br>RFC 1950 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference 2748 was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068. 5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.2778 was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>. 2749 2779 </td> 2750 2780 </tr> … … 2752 2782 <td class="reference"><b id="RFC1951">[RFC1951]</b></td> 2753 2783 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC 1951, May 1996.<br>RFC 1951 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference 2754 was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068. 6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.2784 was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>. 2755 2785 </td> 2756 2786 </tr> … … 2758 2788 <td class="reference"><b id="RFC1952">[RFC1952]</b></td> 2759 2789 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC 1952, May 1996.<br>RFC 1952 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference 2760 was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068. 7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.2790 was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>. 2761 2791 </td> 2762 2792 </tr> … … 2960 2990 <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred 2961 2991 to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single method and no metadata. 2962 HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945. 1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers2992 HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers 2963 2993 on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical 2964 2994 proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented … … 2984 3014 <p id="rfc.section.B.p.5">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 2985 3015 server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described 2986 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068. 8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.3016 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2987 3017 </p> 2988 3018 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> … … 3022 3052 Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when 3023 3053 talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce 3024 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection. 8" title="Connection">Section 9.1</a>.3054 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 9.1</a>. 3025 3055 </p> 3026 3056 <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented 3027 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068. 9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.3057 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 3028 3058 </p> 3029 3059 <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 3035 3065 and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>) 3036 3066 </p> 3037 <p id="rfc.section.B.3.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title=" HTTP Version">Section 2.5</a>)3067 <p id="rfc.section.B.3.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section 2.5</a>) 3038 3068 </p> 3039 3069 <p id="rfc.section.B.3.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) … … 3051 3081 <p id="rfc.section.B.3.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 7.1.4</a>) 3052 3082 </p> 3053 <p id="rfc.section.B.3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection. 9" title="Connection">Section 9.1</a>)3083 <p id="rfc.section.B.3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 9.1</a>) 3054 3084 </p> 3055 3085 <p id="rfc.section.B.3.p.11">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 9.8</a>) … … 3267 3297 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> Since RFC 2616 3268 3298 </h2> 3269 <p id="rfc.section.D.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.3299 <p id="rfc.section.D.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 3270 3300 </p> 3271 3301 <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a> Since draft-ietf-httpbis-p1-messaging-00 … … 3582 3612 </li> 3583 3613 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3584 <li>cache <a href="#rfc.iref.c.3"><b>2. 3</b></a></li>3585 <li>cacheable <a href="#rfc.iref.c.4"><b>2. 3</b></a></li>3614 <li>cache <a href="#rfc.iref.c.3"><b>2.4</b></a></li> 3615 <li>cacheable <a href="#rfc.iref.c.4"><b>2.4</b></a></li> 3586 3616 <li>chunked (Coding Format) <a href="#rfc.iref.c.5">6.2.1</a></li> 3587 3617 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> … … 3596 3626 <li>compress (Coding Format) <a href="#rfc.iref.c.7">6.2.2.1</a></li> 3597 3627 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3598 <li>Connection header field <a href="#rfc.xref.header.connection.1"> 3.4</a>, <a href="#rfc.xref.header.connection.2">7.1.2</a>, <a href="#rfc.xref.header.connection.3">7.1.3</a>, <a href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a href="#rfc.iref.c.11"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.5">9.5</a>, <a href="#rfc.xref.header.connection.6">9.8</a>, <a href="#rfc.xref.header.connection.7">10.1</a>, <a href="#rfc.xref.header.connection.8">B.2</a>, <a href="#rfc.xref.header.connection.9">B.3</a></li>3628 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.c.11"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li> 3599 3629 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.12"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3600 3630 </ul> … … 3603 3633 <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> 3604 3634 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.2.2.2</a></li> 3605 <li>downstream <a href="#rfc.iref.d.1"><b>2. 2</b></a></li>3635 <li>downstream <a href="#rfc.iref.d.1"><b>2.3</b></a></li> 3606 3636 </ul> 3607 3637 </li> … … 3611 3641 </li> 3612 3642 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3613 <li>gateway <a href="#rfc.iref.g.24"><b>2. 2</b></a></li>3643 <li>gateway <a href="#rfc.iref.g.24"><b>2.3</b></a></li> 3614 3644 <li><tt>Grammar</tt> 3615 3645 <ul> … … 3738 3768 <li>Header Fields 3739 3769 <ul> 3740 <li>Connection <a href="#rfc.xref.header.connection.1"> 3.4</a>, <a href="#rfc.xref.header.connection.2">7.1.2</a>, <a href="#rfc.xref.header.connection.3">7.1.3</a>, <a href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.5">9.5</a>, <a href="#rfc.xref.header.connection.6">9.8</a>, <a href="#rfc.xref.header.connection.7">10.1</a>, <a href="#rfc.xref.header.connection.8">B.2</a>, <a href="#rfc.xref.header.connection.9">B.3</a></li>3770 <li>Connection <a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li> 3741 3771 <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> 3742 3772 <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 3787 </li> 3758 3788 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 3759 <li>inbound <a href="#rfc.iref.i.2"><b>2. 2</b></a></li>3760 <li>interception proxy <a href="#rfc.iref.i.3"><b>2. 2</b></a></li>3761 <li>intermediary <a href="#rfc.iref.i.1"><b>2. 2</b></a></li>3789 <li>inbound <a href="#rfc.iref.i.2"><b>2.3</b></a></li> 3790 <li>interception proxy <a href="#rfc.iref.i.3"><b>2.3</b></a></li> 3791 <li>intermediary <a href="#rfc.iref.i.1"><b>2.3</b></a></li> 3762 3792 <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> 3763 3793 </ul> … … 3780 3810 <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 3781 3811 <li><em>Nie1997</em> <a href="#rfc.xref.Nie1997.1">7.1.1</a>, <a href="#Nie1997"><b>13.2</b></a></li> 3782 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2. 2</b></a></li>3812 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2.3</b></a></li> 3783 3813 </ul> 3784 3814 </li> 3785 3815 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3786 3816 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3787 <li>outbound <a href="#rfc.iref.o.2"><b>2. 2</b></a></li>3817 <li>outbound <a href="#rfc.iref.o.2"><b>2.3</b></a></li> 3788 3818 </ul> 3789 3819 </li> … … 3810 3840 </ul> 3811 3841 </li> 3812 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.3">1.2.3</a>, <a href="#rfc.xref.Part6.4">2. 3</a>, <a href="#rfc.xref.Part6.5">3.3</a>, <a href="#rfc.xref.Part6.6">3.4</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a>, <a href="#Part6"><b>13.1</b></a><ul>3813 <li><em>Section 2</em> <a href="#rfc.xref.Part6.4">2. 3</a></li>3842 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.3">1.2.3</a>, <a href="#rfc.xref.Part6.4">2.4</a>, <a href="#rfc.xref.Part6.5">3.3</a>, <a href="#rfc.xref.Part6.6">3.4</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a>, <a href="#Part6"><b>13.1</b></a><ul> 3843 <li><em>Section 2</em> <a href="#rfc.xref.Part6.4">2.4</a></li> 3814 3844 <li><em>Section 2.1.1</em> <a href="#rfc.xref.Part6.5">3.3</a></li> 3815 3845 <li><em>Section 3.4</em> <a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.6">3.4</a></li> … … 3818 3848 </li> 3819 3849 <li>path-absolute form (of request-target) <a href="#rfc.iref.p.2">4.1.2</a></li> 3820 <li>proxy <a href="#rfc.iref.p.1"><b>2. 2</b></a></li>3850 <li>proxy <a href="#rfc.iref.p.1"><b>2.3</b></a></li> 3821 3851 </ul> 3822 3852 </li> … … 3825 3855 <li>resource <a href="#rfc.iref.r.4"><b>2.6</b></a></li> 3826 3856 <li>response <a href="#rfc.iref.r.2"><b>2.1</b></a></li> 3827 <li>reverse proxy <a href="#rfc.iref.r.3"><b>2. 2</b></a></li>3857 <li>reverse proxy <a href="#rfc.iref.r.3"><b>2.3</b></a></li> 3828 3858 <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> 3829 3859 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">6.1</a></li> … … 3831 3861 </li> 3832 3862 <li><em>RFC1900</em> <a href="#rfc.xref.RFC1900.1">11.4</a>, <a href="#RFC1900"><b>13.2</b></a></li> 3833 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2. 2</a>, <a href="#RFC1919"><b>13.2</b></a></li>3834 <li><em>RFC1945</em> <a href="# RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.1">B</a></li>3863 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>13.2</b></a></li> 3864 <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> 3835 3865 <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> 3836 3866 <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> … … 3841 3871 </li> 3842 3872 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li> 3843 <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</a>, <a href="#rfc.xref.RFC2068.9">B.2</a><ul>3844 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068. 2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B</a>, <a href="#rfc.xref.RFC2068.9">B.2</a></li>3873 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">7.1.3</a>, <a href="#rfc.xref.RFC2068.2">7.2.3</a>, <a href="#rfc.xref.RFC2068.3">12</a>, <a href="#rfc.xref.RFC2068.4">13.1</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.7">B</a>, <a href="#rfc.xref.RFC2068.8">B.2</a><ul> 3874 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.1">7.1.3</a>, <a href="#rfc.xref.RFC2068.7">B</a>, <a href="#rfc.xref.RFC2068.8">B.2</a></li> 3845 3875 </ul> 3846 3876 </li> 3847 3877 <li><em>RFC2109</em> <a href="#rfc.xref.RFC2109.1">3.2</a>, <a href="#RFC2109"><b>13.2</b></a></li> 3848 3878 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>13.1</b></a></li> 3849 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1"> 2.5</a>, <a href="#rfc.xref.RFC2145.2">2.5</a>, <a href="#RFC2145"><b>13.2</b></a></li>3850 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2"> 12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.3">D.1</a></li>3879 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#RFC2145"><b>13.2</b></a></li> 3880 <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> 3851 3881 <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.3</a><ul> 3852 3882 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.1">10.5</a></li> … … 3855 3885 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2.6.2</a>, <a href="#RFC2818"><b>13.2</b></a></li> 3856 3886 <li><em>RFC2965</em> <a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>13.2</b></a></li> 3857 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2. 2</a>, <a href="#RFC3040"><b>13.2</b></a></li>3887 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>13.2</b></a></li> 3858 3888 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">10.1</a>, <a href="#RFC3864"><b>13.2</b></a></li> 3859 3889 <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> … … 3902 3932 <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> 3903 3933 <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.3</a>, <a href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.5">10.1</a></li> 3904 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2. 2</b></a></li>3905 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2. 2</b></a></li>3906 <li>tunnel <a href="#rfc.iref.t.2"><b>2. 2</b></a></li>3934 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.3</b></a></li> 3935 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.3</b></a></li> 3936 <li>tunnel <a href="#rfc.iref.t.2"><b>2.3</b></a></li> 3907 3937 </ul> 3908 3938 </li> 3909 3939 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3910 3940 <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.3</a></li> 3911 <li>upstream <a href="#rfc.iref.u.2"><b>2. 2</b></a></li>3941 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3912 3942 <li>URI scheme 3913 3943 <ul>
Note: See TracChangeset
for help on using the changeset viewer.