Changeset 1837 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 20/08/12 06:04:26 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1836 r1837 582 582 <li><a href="#rfc.section.2.1">2.1</a> <a href="#operation">Client/Server Messaging</a></li> 583 583 <li><a href="#rfc.section.2.2">2.2</a> <a href="#implementation-diversity">Implementation Diversity</a></li> 584 <li><a href="#rfc.section.2.3">2.3</a> <a href="#transport-independence">Connections and Transport Independence</a></li> 585 <li><a href="#rfc.section.2.4">2.4</a> <a href="#intermediaries">Intermediaries</a></li> 586 <li><a href="#rfc.section.2.5">2.5</a> <a href="#caches">Caches</a></li> 587 <li><a href="#rfc.section.2.6">2.6</a> <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 588 <li><a href="#rfc.section.2.7">2.7</a> <a href="#http.version">Protocol Versioning</a></li> 589 <li><a href="#rfc.section.2.8">2.8</a> <a href="#uri">Uniform Resource Identifiers</a><ul> 590 <li><a href="#rfc.section.2.8.1">2.8.1</a> <a href="#http.uri">http URI scheme</a></li> 591 <li><a href="#rfc.section.2.8.2">2.8.2</a> <a href="#https.uri">https URI scheme</a></li> 592 <li><a href="#rfc.section.2.8.3">2.8.3</a> <a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 584 <li><a href="#rfc.section.2.3">2.3</a> <a href="#intermediaries">Intermediaries</a></li> 585 <li><a href="#rfc.section.2.4">2.4</a> <a href="#caches">Caches</a></li> 586 <li><a href="#rfc.section.2.5">2.5</a> <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 587 <li><a href="#rfc.section.2.6">2.6</a> <a href="#http.version">Protocol Versioning</a></li> 588 <li><a href="#rfc.section.2.7">2.7</a> <a href="#uri">Uniform Resource Identifiers</a><ul> 589 <li><a href="#rfc.section.2.7.1">2.7.1</a> <a href="#http.uri">http URI scheme</a></li> 590 <li><a href="#rfc.section.2.7.2">2.7.2</a> <a href="#https.uri">https URI scheme</a></li> 591 <li><a href="#rfc.section.2.7.3">2.7.3</a> <a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 593 592 </ul> 594 593 </li> … … 648 647 <li><a href="#rfc.section.6.1">6.1</a> <a href="#header.connection">Connection</a></li> 649 648 <li><a href="#rfc.section.6.2">6.2</a> <a href="#persistent.connections">Persistent Connections</a><ul> 650 <li><a href="#rfc.section.6.2.1">6.2.1</a> <a href="#persistent.purpose">Purpose</a></li> 651 <li><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#persistent.overall">Overall Operation</a><ul> 652 <li><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a href="#persistent.negotiation">Negotiation</a></li> 653 <li><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a href="#pipelining">Pipelining</a></li> 649 <li><a href="#rfc.section.6.2.1">6.2.1</a> <a href="#persistent.overall">Overall Operation</a><ul> 650 <li><a href="#rfc.section.6.2.1.1">6.2.1.1</a> <a href="#persistent.negotiation">Negotiation</a></li> 651 <li><a href="#rfc.section.6.2.1.2">6.2.1.2</a> <a href="#pipelining">Pipelining</a></li> 654 652 </ul> 655 653 </li> 656 <li><a href="#rfc.section.6.2. 3">6.2.3</a> <a href="#persistent.practical">Practical Considerations</a></li>657 <li><a href="#rfc.section.6.2. 4">6.2.4</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li>654 <li><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#persistent.practical">Practical Considerations</a></li> 655 <li><a href="#rfc.section.6.2.3">6.2.3</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 658 656 </ul> 659 657 </li> … … 812 810 <div id="rfc.iref.c.2"></div> 813 811 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="operation" href="#operation">Client/Server Messaging</a></h2> 814 <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging <dfn>messages</dfn> (<a href="#http.message" title="Message Format">Section 3</a>) across a reliable transport or session-layer "<dfn>connection</dfn>" . An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.812 <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging <dfn>messages</dfn> (<a href="#http.message" title="Message Format">Section 3</a>) across a reliable transport or session-layer "<dfn>connection</dfn>" (<a href="#connection.management" title="Connection Management">Section 6</a>). An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses. 815 813 </p> 816 814 <div id="rfc.iref.u.1"></div> … … 842 840 phrase (<a href="#status.line" title="Status Line">Section 3.1.2</a>), possibly followed by header fields containing server information, resource metadata, and representation metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 843 841 </p> 844 <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 842 <p id="rfc.section.2.1.p.8">A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>. 843 </p> 844 <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 845 845 <div id="rfc.figure.u.2"></div> 846 846 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 … … 879 879 run-time options, or simply not proceeding with the unsafe action. 880 880 </p> 881 <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>882 <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 reliable883 transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request884 and response structures onto the data units of the underlying transport protocol is outside the scope of this specification.885 </p>886 <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 URI887 (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>). For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.8.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use888 a proxy via some other connection port or protocol instead of using the defaults.889 </p>890 <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 6.2</a>.891 </p>892 881 <div id="rfc.iref.i.1"></div> 893 <h2 id="rfc.section.2. 4"><a href="#rfc.section.2.4">2.4</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>894 <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 of882 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 883 <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 895 884 HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, 896 885 switching behavior based on the nature of each request. … … 899 888 <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b> 900 889 < < < < 901 </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 response890 </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 902 891 message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply 903 892 only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along … … 906 895 at the same time that it is handling A's request. 907 896 </p> 908 <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.897 <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. 909 898 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. 910 899 </p> 911 <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 requests900 <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests 912 901 for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations 913 902 are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely … … 915 904 for the sake of security, annotation services, or shared caching. 916 905 </p> 917 <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,906 <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, 918 907 beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original 919 908 sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared … … 923 912 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 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 924 913 </p> 925 <p id="rfc.section.2. 4.p.7"><span id="rfc.iref.g.13"></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 underlying914 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></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 926 915 server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance 927 916 through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. 928 917 </p> 929 <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 requirements918 <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements 930 919 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 931 920 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 932 921 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 5.7</a>) header fields for both connections. 933 922 </p> 934 <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 party923 <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party 935 924 to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both 936 925 ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 937 926 when transport-layer security is used to establish confidential communication through a shared firewall proxy. 938 927 </p> 939 <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> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also928 <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> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also 940 929 intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the 941 930 knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems … … 945 934 and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack. 946 935 </p> 947 <p id="rfc.section.2. 4.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations936 <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations 948 937 depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple 949 938 servers. Hence, servers <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific … … 951 940 </p> 952 941 <div id="rfc.iref.c.4"></div> 953 <h2 id="rfc.section.2. 5"><a href="#rfc.section.2.5">2.5</a> <a id="caches" href="#caches">Caches</a></h2>954 <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.942 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="caches" href="#caches">Caches</a></h2> 943 <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. 955 944 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 956 945 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. 957 946 </p> 958 <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 cached947 <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 959 948 response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response 960 949 from O (via C) for a request which has not been cached by UA or A. … … 963 952 <b>UA</b> =========== <b>A</b> =========== <b>B</b> - - - - - - <b>C</b> - - - - - - <b>O</b> 964 953 < < 965 </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 response954 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 966 955 is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 967 956 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="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 968 957 </p> 969 <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 and958 <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 970 959 inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems 971 960 that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so 972 961 on. 973 962 </p> 974 <h2 id="rfc.section.2. 6"><a href="#rfc.section.2.6">2.6</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>975 <p id="rfc.section.2. 6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP963 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 964 <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 976 965 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 977 966 or caches, depending on what behavior is being constrained by the requirement. 978 967 </p> 979 <p id="rfc.section.2. 6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely968 <p id="rfc.section.2.5.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 980 969 forwarding a received element downstream. 981 970 </p> 982 <p id="rfc.section.2. 6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes971 <p id="rfc.section.2.5.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 983 972 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 984 973 </p> 985 <p id="rfc.section.2. 6.p.4">In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable974 <p id="rfc.section.2.5.p.4">In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 986 975 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 987 976 to the recipient's role. 988 977 </p> 989 <p id="rfc.section.2. 6.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms978 <p id="rfc.section.2.5.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 990 979 except when they have a direct impact on security, since different applications of the protocol require different error handling 991 980 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 992 981 to be dangerous. 993 982 </p> 994 <h2 id="rfc.section.2. 7"><a href="#rfc.section.2.7">2.7</a> <a id="http.version" href="#http.version">Protocol Versioning</a></h2>995 <p id="rfc.section.2. 7.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1".983 <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> 984 <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". 996 985 The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's 997 986 corresponding specification of HTTP. 998 987 </p> 999 <p id="rfc.section.2. 7.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>988 <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> 1000 989 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#http.version" class="smpl">HTTP-version</a> = <a href="#http.version" class="smpl">HTTP-name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a> 1001 990 <a href="#http.version" class="smpl">HTTP-name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 1002 </pre><p id="rfc.section.2. 7.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major991 </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 1003 992 version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version 1004 993 to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's … … 1006 995 the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). 1007 996 </p> 1008 <p id="rfc.section.2. 7.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.0997 <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 1009 998 message if all of the newer features are ignored. This specification places recipient-version requirements on some new features 1010 999 so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt 1011 1000 of a message, that the recipient supports HTTP/1.1. 1012 1001 </p> 1013 <p id="rfc.section.2. 7.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default1002 <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default 1014 1003 behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 1015 1004 are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. 1016 1005 </p> 1017 <p id="rfc.section.2. 7.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation1006 <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 1018 1007 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 1019 1008 by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's <a href="#header.connection" class="smpl">Connection</a> header field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries. 1020 1009 </p> 1021 <p id="rfc.section.2. 7.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <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 in that message matches a version1010 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <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 in that message matches a version 1022 1011 to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without 1023 1012 rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version 1024 1013 to determine what features are safe to use for later communication with that sender. 1025 1014 </p> 1026 <p id="rfc.section.2. 7.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher1015 <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 to which the client is conformant and whose major version is no higher 1027 1016 than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. 1028 1017 </p> 1029 <p id="rfc.section.2. 7.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 after1018 <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 1030 1019 the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions. 1031 1020 </p> 1032 <p id="rfc.section.2. 7.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than1021 <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 to which the server is conformant and whose major version is less than 1033 1022 or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not 1034 1023 Supported)</a> response if it cannot send a response using the major version used in the client's request. 1035 1024 </p> 1036 <p id="rfc.section.2. 7.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 HTTP1025 <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 1037 1026 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 1038 1027 number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the 1039 1028 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., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error. 1040 1029 </p> 1041 <p id="rfc.section.2. 7.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax1030 <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 1042 1031 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1043 1032 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented … … 1045 1034 </p> 1046 1035 <div id="rfc.iref.r.5"></div> 1047 <h2 id="rfc.section.2. 8"><a href="#rfc.section.2.8">2.8</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>1048 <p id="rfc.section.2. 8.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,1036 <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> 1037 <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, 1049 1038 and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to 1050 1039 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>. 1051 1040 </p> 1052 <p id="rfc.section.2. 8.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",1041 <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", 1053 1042 "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. 1054 1043 </p> … … 1064 1053 1065 1054 <a href="#uri" class="smpl">partial-URI</a> = relative-part [ "?" query ] 1066 </pre><p id="rfc.section.2. 8.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows1055 </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 1067 1056 any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, 1068 1057 or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request 1069 1058 URI (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>). 1070 1059 </p> 1071 <h3 id="rfc.section.2. 8.1"><a href="#rfc.section.2.8.1">2.8.1</a> <a id="http.uri" href="#http.uri">http URI scheme</a></h3>1060 <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> 1072 1061 <div id="rfc.iref.h.1"></div> 1073 1062 <div id="rfc.iref.u.3"></div> 1074 <p id="rfc.section.2. 8.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical1063 <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 1075 1064 namespace governed by a potential HTTP origin server listening for TCP connections on a given port. 1076 1065 </p> 1077 1066 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.24"></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> ] 1078 </pre><p id="rfc.section.2. 8.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 an1067 </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 1079 1068 identifier for a potential resource within that origin server's name space. 1080 1069 </p> 1081 <p id="rfc.section.2. 8.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 indicated1070 <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 1082 1071 TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient 1083 1072 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 1084 1073 port for WWW services). 1085 1074 </p> 1086 <p id="rfc.section.2. 8.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.1075 <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. 1087 1076 The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening 1088 1077 to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish … … 1090 1079 authority to determine which names are valid and how they might be used. 1091 1080 </p> 1092 <p id="rfc.section.2. 8.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,1081 <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, 1093 1082 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1094 1083 </p> 1095 <p id="rfc.section.2. 8.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name1084 <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 1096 1085 delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol 1097 1086 would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require … … 1099 1088 — it is only the authoritative interface used for mapping the namespace that is specific to TCP. 1100 1089 </p> 1101 <p id="rfc.section.2. 8.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 internal1090 <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 1102 1091 configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, 1103 1092 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 … … 1105 1094 is being used to obscure the authority for the sake of phishing attacks. 1106 1095 </p> 1107 <h3 id="rfc.section.2. 8.2"><a href="#rfc.section.2.8.2">2.8.2</a> <a id="https.uri" href="#https.uri">https URI scheme</a></h3>1096 <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> 1108 1097 <div id="rfc.iref.h.2"></div> 1109 1098 <div id="rfc.iref.u.4"></div> 1110 <p id="rfc.section.2. 8.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical1099 <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 1111 1100 namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. 1112 1101 </p> 1113 <p id="rfc.section.2. 8.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default1102 <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 1114 1103 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 through the use of strong encryption prior to sending the first HTTP request. 1115 1104 </p> 1116 1105 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></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> ] 1117 </pre><p id="rfc.section.2. 8.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 HTTP1106 </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 1118 1107 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1119 1108 </p> 1120 <p id="rfc.section.2. 8.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers1109 <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 1121 1110 indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered 1122 1111 to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the 1123 1112 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. 1124 1113 </p> 1125 <p id="rfc.section.2. 8.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>.1126 </p> 1127 <h3 id="rfc.section.2. 8.3"><a href="#rfc.section.2.8.3">2.8.3</a> <a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3>1128 <p id="rfc.section.2. 8.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to1114 <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>. 1115 </p> 1116 <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> 1117 <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 1129 1118 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. 1130 1119 </p> 1131 <p id="rfc.section.2. 8.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 empty1120 <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 1132 1121 path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme 1133 1122 and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. 1134 1123 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. 1135 1124 </p> 1136 <p id="rfc.section.2. 8.3.p.3">For example, the following three URIs are equivalent:</p>1125 <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p> 1137 1126 <div id="rfc.figure.u.10"></div><pre class="text"> http://example.com:80/~smith/home.html 1138 1127 http://EXAMPLE.com/%7Esmith/home.html … … 1517 1506 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data 1518 1507 on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple 1519 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.2. 2.2</a>.1508 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.2.1.2</a>. 1520 1509 </p> 1521 1510 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> … … 1697 1686 </p> 1698 1687 <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which 1699 are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2. 8</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers are reserved1688 are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers are reserved 1700 1689 for client-side processing (<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-3.5">Section 3.5</a>). 1701 1690 </p> … … 1715 1704 connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and 1716 1705 defined by its associated specification, similar to how this specification defines origin server access for resolution of 1717 the "http" (<a href="#http.uri" title="http URI scheme">Section 2.8.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section 2.8.2</a>) schemes. 1706 the "http" (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) schemes. 1707 </p> 1708 <p id="rfc.section.5.2.p.5">HTTP requirements regarding connection management are defined in <a href="#connection.management" title="Connection Management">Section 6</a>. 1718 1709 </p> 1719 1710 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="request-target" href="#request-target">Request Target</a></h2> 1720 <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained (<a href="#connection.management" title="Connection Management">Section 6</a>), the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on1711 <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on 1721 1712 both the method being requested and whether the request is to a proxy. 1722 1713 </p> … … 1781 1772 is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line. 1782 1773 </p> 1783 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.84"></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. 8.1</a>1774 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.84"></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> 1784 1775 </pre><p id="rfc.section.5.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 URI includes an authority component, then the Host 1785 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. 8.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.1776 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 URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 1786 1777 </p> 1787 1778 <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> … … 1841 1832 </p> 1842 1833 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2> 1843 <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section 2. 4</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used1834 <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section 2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used 1844 1835 to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has 1845 1836 characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can … … 1946 1937 </p> 1947 1938 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connection.management" href="#connection.management">Connection Management</a></h1> 1939 <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable 1940 transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request 1941 and response structures onto the data units of an underlying transport protocol is outside the scope of this specification. 1942 </p> 1943 <p id="rfc.section.6.p.2">As described in <a href="#connecting.inbound" title="Connecting Inbound">Section 5.2</a>, the specific connection protocols to be used for an HTTP interaction are determined by client configuration and the <a href="#target-resource" class="smpl">target URI</a>. 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 1944 a proxy via some other connection, port, or protocol. 1945 </p> 1946 <p id="rfc.section.6.p.3">HTTP implementations are expected to engage in connection management, which includes maintaining the state of current connections, 1947 establishing a new connection or reusing an existing connection, processing messages received on a connection, detecting connection 1948 failures, and closing each connection. Most clients maintain multiple connections in parallel, including more than one connection 1949 per server endpoint. Most servers are designed to maintain thousands of concurrent connections, while controlling request 1950 queues to enable fair use and detect denial of service attacks. 1951 </p> 1948 1952 <div id="rfc.iref.c.13"></div> 1949 1953 <div id="rfc.iref.h.13"></div> 1950 1954 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1951 <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such 1952 connection options <em class="bcp14">MUST</em> be removed or replaced before the message can be forwarded downstream by a proxy or gateway. This mechanism also allows the 1953 sender to indicate which HTTP header fields used in the message are only intended for the immediate recipient ("hop-by-hop"), 1954 as opposed to all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future 1955 connection-specific extensions to be deployed in HTTP without fear that they will be blindly forwarded by previously deployed 1956 intermediaries. 1957 </p> 1958 <p id="rfc.section.6.1.p.2">The Connection header field's value has the following grammar:</p> 1955 <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to 1956 avoid confusing downstream recipients, a proxy or gateway <em class="bcp14">MUST</em> remove or replace any received connection options before forwarding the message. 1957 </p> 1958 <p id="rfc.section.6.1.p.2">When a header field is used to supply control information for or about the current connection, the sender <em class="bcp14">SHOULD</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove 1959 any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field 1960 itself (or replace it with the intermediary's own connection options for the forwarded message). 1961 </p> 1962 <p id="rfc.section.6.1.p.3">Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the 1963 immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling 1964 the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they 1965 will be blindly forwarded by older intermediaries. 1966 </p> 1967 <p id="rfc.section.6.1.p.4">The Connection header field's value has the following grammar:</p> 1959 1968 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> 1960 1969 <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a> 1961 </pre><p id="rfc.section.6.1.p.4">Connection options are compared case-insensitively.</p> 1962 <p id="rfc.section.6.1.p.5">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove 1963 any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field 1964 itself or replace it with the sender's own connection options for the forwarded message. 1965 </p> 1966 <p id="rfc.section.6.1.p.6">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 1970 </pre><p id="rfc.section.6.1.p.6">Connection options are compared case-insensitively.</p> 1971 <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 1967 1972 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1968 1973 </p> 1969 <p id="rfc.section.6.1.p. 7">The connection options do not have to correspond to a header field present in the message, since a connection-specific header1974 <p id="rfc.section.6.1.p.8">The connection options do not have to correspond to a header field present in the message, since a connection-specific header 1970 1975 field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain 1971 1976 connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-option rather than only the presence of the optional header field. In other … … 1974 1979 conformant. 1975 1980 </p> 1976 <p id="rfc.section.6.1.p. 8">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure1981 <p id="rfc.section.6.1.p.9">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure 1977 1982 that the new connection option does not share the same name as an unrelated header field that might already be deployed. Defining 1978 1983 a new connection option essentially reserves that potential field-name for carrying additional information related to the 1979 1984 connection option, since it would be unwise for senders to use that field-name for anything else. 1980 1985 </p> 1981 <p id="rfc.section.6.1.p. 9">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion1986 <p id="rfc.section.6.1.p.10">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion 1982 1987 of the response. For example, 1983 1988 </p> 1984 1989 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 1985 </pre><p id="rfc.section.6.1.p.1 1">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>) after the current request/response is complete.1986 </p> 1987 <p id="rfc.section.6.1.p.1 2">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.1988 </p> 1989 <p id="rfc.section.6.1.p.1 3">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code.1990 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>). 1991 </p> 1992 <p id="rfc.section.6.1.p.13">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message. 1993 </p> 1994 <p id="rfc.section.6.1.p.14">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code. 1990 1995 </p> 1991 1996 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> 1992 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> 1993 <p id="rfc.section.6.2.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers 1994 and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make 1995 multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a 1996 prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. 1997 </p> 1998 <p id="rfc.section.6.2.1.p.2">Persistent HTTP connections have a number of advantages: </p> 1999 <ul> 2000 <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, 2001 tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts. 2002 </li> 2003 <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without 2004 waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. 2005 </li> 2006 <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to 2007 determine the congestion state of the network. 2008 </li> 2009 <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li> 2010 <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using 2011 future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old 2012 semantics after an error is reported. 2013 </li> 2014 </ul> 2015 <p id="rfc.section.6.2.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. 2016 </p> 2017 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3> 2018 <p id="rfc.section.6.2.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior 1997 <p id="rfc.section.6.2.p.1">HTTP was originally designed to use a separate connection for each request/response pair. As the Web evolved and embedded 1998 requests became common for inline images, the connection establishment overhead was a significant drain on performance and 1999 a concern for Internet congestion. Message framing (via <a href="#header.content-length" class="smpl">Content-Length</a>) and optional long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order to improve performance for some requests. 2000 However, these extensions were insufficient for dynamically generated responses and difficult to use with intermediaries. 2001 </p> 2002 <p id="rfc.section.6.2.p.2">HTTP/1.1 defaults to the use of "<a href="#persistent.connections" class="smpl">persistent connections</a>", which allow multiple requests and responses to be carried over a single connection. Persistent connections have a number 2003 of advantages: 2004 </p> 2005 <ul> 2006 <li>By opening and closing fewer connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, 2007 or caches), and memory used for protocol control blocks can be saved in hosts. 2008 </li> 2009 <li>Most requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without 2010 waiting for each response, allowing a single connection to be used much more efficiently and with less overall latency. 2011 </li> 2012 <li>Network congestion is reduced by reducing the number of packets caused by connection establishment and tear-down, and by allowing 2013 sufficient time for send/receive windows to adjust to the available network bandwidth. 2014 </li> 2015 <li>Latency on subsequent requests is reduced since there is no time spent in the connection opening handshake.</li> 2016 <li>HTTP can evolve more gracefully, since most errors can be reported without the penalty of closing the connection. Clients 2017 using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with 2018 old semantics after an error is reported. 2019 </li> 2020 </ul> 2021 <p id="rfc.section.6.2.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. 2022 </p> 2023 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3> 2024 <p id="rfc.section.6.2.1.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior 2019 2025 of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server. 2020 2026 </p> 2021 <p id="rfc.section.6.2. 2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling2027 <p id="rfc.section.6.2.1.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 2022 2028 takes place using the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 2023 2029 </p> 2024 <h4 id="rfc.section.6.2. 2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>2025 <p id="rfc.section.6.2. 2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection2030 <h4 id="rfc.section.6.2.1.1"><a href="#rfc.section.6.2.1.1">6.2.1.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> 2031 <p id="rfc.section.6.2.1.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection 2026 2032 immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2027 2033 </p> 2028 <p id="rfc.section.6.2. 2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains2034 <p id="rfc.section.6.2.1.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains 2029 2035 a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that 2030 2036 request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2031 2037 </p> 2032 <p id="rfc.section.6.2. 2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection.2033 </p> 2034 <p id="rfc.section.6.2. 2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.2035 </p> 2036 <p id="rfc.section.6.2. 2.1.p.5">Each persistent connection applies to only one transport link.</p>2037 <p id="rfc.section.6.2. 2.1.p.6">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.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).2038 </p> 2039 <p id="rfc.section.6.2. 2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>.2040 </p> 2041 <h4 id="rfc.section.6.2. 2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4>2042 <p id="rfc.section.6.2. 2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.2043 </p> 2044 <p id="rfc.section.6.2. 2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.2045 </p> 2046 <p id="rfc.section.6.2. 2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2038 <p id="rfc.section.6.2.1.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection. 2039 </p> 2040 <p id="rfc.section.6.2.1.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 2041 </p> 2042 <p id="rfc.section.6.2.1.1.p.5">Each persistent connection applies to only one transport link.</p> 2043 <p id="rfc.section.6.2.1.1.p.6">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.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 2044 </p> 2045 <p id="rfc.section.6.2.1.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 2046 </p> 2047 <h4 id="rfc.section.6.2.1.2"><a href="#rfc.section.6.2.1.2">6.2.1.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> 2048 <p id="rfc.section.6.2.1.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received. 2049 </p> 2050 <p id="rfc.section.6.2.1.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2051 </p> 2052 <p id="rfc.section.6.2.1.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2047 2053 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2048 2054 </p> 2049 <h3 id="rfc.section.6.2. 3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>2050 <p id="rfc.section.6.2. 3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers2055 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> 2056 <p id="rfc.section.6.2.2.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers 2051 2057 might make this a higher value since it is likely that the client will be making more connections through the same server. 2052 2058 The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client 2053 2059 or the server. 2054 2060 </p> 2055 <p id="rfc.section.6.2. 3.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does2061 <p id="rfc.section.6.2.2.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does 2056 2062 not detect the other side's close promptly it could cause unnecessary resource drain on the network. 2057 2063 </p> 2058 <p id="rfc.section.6.2. 3.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time2064 <p id="rfc.section.6.2.2.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time 2059 2065 that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed 2060 2066 while it was idle, but from the client's point of view, a request is in progress. 2061 2067 </p> 2062 <p id="rfc.section.6.2. 3.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).2063 </p> 2064 <p id="rfc.section.6.2. 3.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many2068 <p id="rfc.section.6.2.2.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies). 2069 </p> 2070 <p id="rfc.section.6.2.2.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many 2065 2071 applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages 2066 2072 clients to be conservative when opening multiple connections. 2067 2073 </p> 2068 <p id="rfc.section.6.2. 3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant2074 <p id="rfc.section.6.2.2.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant 2069 2075 server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used 2070 2076 consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side 2071 2077 effects in congested networks. 2072 2078 </p> 2073 <p id="rfc.section.6.2. 3.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>2074 <h3 id="rfc.section.6.2. 4"><a href="#rfc.section.6.2.4">6.2.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>2075 <p id="rfc.section.6.2. 4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request2079 <p id="rfc.section.6.2.2.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> 2080 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2081 <p id="rfc.section.6.2.3.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2076 2082 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2077 2083 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. … … 2175 2181 </p> 2176 2182 <p id="rfc.section.6.4.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2177 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2. 7</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined2183 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 2178 2184 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. 2179 2185 </p> … … 2300 2306 <td class="left">http</td> 2301 2307 <td class="left">Hypertext Transfer Protocol</td> 2302 <td class="left"><a href="#http.uri" title="http URI scheme">Section 2. 8.1</a></td>2308 <td class="left"><a href="#http.uri" title="http URI scheme">Section 2.7.1</a></td> 2303 2309 </tr> 2304 2310 <tr> 2305 2311 <td class="left">https</td> 2306 2312 <td class="left">Hypertext Transfer Protocol Secure</td> 2307 <td class="left"><a href="#https.uri" title="https URI scheme">Section 2. 8.2</a></td>2313 <td class="left"><a href="#https.uri" title="https URI scheme">Section 2.7.2</a></td> 2308 2314 </tr> 2309 2315 </tbody> … … 2522 2528 <td class="left">Hypertext Transfer Protocol</td> 2523 2529 <td class="left">any DIGIT.DIGIT (e.g, "2.0")</td> 2524 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2. 7</a></td>2530 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2.6</a></td> 2525 2531 </tr> 2526 2532 </tbody> … … 2699 2705 <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References 2700 2706 </h2> 2701 <table> 2707 <table> 2702 2708 <tr> 2703 2709 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> … … 2707 2713 <td class="reference"><b id="Kri2001">[Kri2001]</b></td> 2708 2714 <td class="top">Kristol, D., “<a href="http://arxiv.org/abs/cs.SE/0105018">HTTP Cookies: Standards, Privacy, and Politics</a>”, ACM Transactions on Internet Technology Vol. 1, #2, November 2001, <<a href="http://arxiv.org/abs/cs.SE/0105018">http://arxiv.org/abs/cs.SE/0105018</a>>. 2709 </td>2710 </tr>2711 <tr>2712 <td class="reference"><b id="Nie1997">[Nie1997]</b></td>2713 <td class="top">Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “<a href="http://doi.acm.org/10.1145/263105.263157">Network Performance Effects of HTTP/1.1, CSS1, and PNG</a>”, ACM Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication2714 SIGCOMM '97, September 1997, <<a href="http://doi.acm.org/10.1145/263105.263157">http://doi.acm.org/10.1145/263105.263157</a>>.2715 </td>2716 </tr>2717 <tr>2718 <td class="reference"><b id="Pad1995">[Pad1995]</b></td>2719 <td class="top">Padmanabhan, V. and J. Mogul, “<a href="http://portal.acm.org/citation.cfm?id=219094">Improving HTTP Latency</a>”, Computer Networks and ISDN Systems v. 28, pp. 25-35, December 1995, <<a href="http://portal.acm.org/citation.cfm?id=219094">http://portal.acm.org/citation.cfm?id=219094</a>>.2720 2715 </td> 2721 2716 </tr> … … 2815 2810 </td> 2816 2811 </tr> 2817 <tr>2818 <td class="reference"><b id="Spe">[Spe]</b></td>2819 <td class="top">Spero, S., “<a href="http://sunsite.unc.edu/mdma-release/http-prob.html">Analysis of HTTP Performance Problems</a>”, <<a href="http://sunsite.unc.edu/mdma-release/http-prob.html">http://sunsite.unc.edu/mdma-release/http-prob.html</a>>.2820 </td>2821 </tr>2822 <tr>2823 <td class="reference"><b id="Tou1998">[Tou1998]</b></td>2824 <td class="top"><a href="mailto:touch@isi.edu" title="USC/Information Sciences Institute">Touch, J.</a>, <a href="mailto:johnh@isi.edu" title="USC/Information Sciences Institute">Heidemann, J.</a>, and <a href="mailto:katia@isi.edu" title="USC/Information Sciences Institute">K. Obraczka</a>, “<a href="http://www.isi.edu/touch/pubs/http-perf96/">Analysis of HTTP Performance</a>”, ISI Research Report ISI/RR-98-463, Aug 1998, <<a href="http://www.isi.edu/touch/pubs/http-perf96/">http://www.isi.edu/touch/pubs/http-perf96/</a>>.<br>(original report dated Aug. 1996)2825 </td>2826 </tr>2827 2812 </table> 2828 2813 <div class="avoidbreak"> … … 2895 2880 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 2896 2881 <p id="rfc.section.A.2.p.1">Clarify that the string "HTTP" in the HTTP-version ABNF production is case sensitive. Restrict the version numbers to be single 2897 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. 7</a>)2882 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>) 2898 2883 </p> 2899 2884 <p id="rfc.section.A.2.p.2">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk … … 2921 2906 </p> 2922 2907 <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent. 2923 Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section 6.2. 3</a>)2908 Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section 6.2.2</a>) 2924 2909 </p> 2925 2910 <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain circumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section 6.3</a>) … … 3491 3476 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3492 3477 <li>absolute-form (of request-target) <a href="#rfc.iref.a.2">5.3</a></li> 3493 <li>accelerator <a href="#rfc.iref.a.1"><b>2. 4</b></a></li>3478 <li>accelerator <a href="#rfc.iref.a.1"><b>2.3</b></a></li> 3494 3479 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>7.3.2</b></a></li> 3495 3480 <li>asterisk-form (of request-target) <a href="#rfc.iref.a.4">5.3</a></li> … … 3502 3487 </li> 3503 3488 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3504 <li>cache <a href="#rfc.iref.c.4"><b>2. 5</b></a></li>3505 <li>cacheable <a href="#rfc.iref.c.5"><b>2. 5</b></a></li>3506 <li>captive portal <a href="#rfc.iref.c.3"><b>2. 4</b></a></li>3489 <li>cache <a href="#rfc.iref.c.4"><b>2.4</b></a></li> 3490 <li>cacheable <a href="#rfc.iref.c.5"><b>2.4</b></a></li> 3491 <li>captive portal <a href="#rfc.iref.c.3"><b>2.3</b></a></li> 3507 3492 <li>chunked (Coding Format) <a href="#rfc.iref.c.7">4.1</a></li> 3508 3493 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> … … 3517 3502 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3518 3503 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3519 <li>Connection header field <a href="#rfc.xref.header.connection.1">2. 4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.2</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>3504 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.1</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li> 3520 3505 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3521 3506 </ul> … … 3523 3508 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3524 3509 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">4.2.2</a></li> 3525 <li>downstream <a href="#rfc.iref.d.1"><b>2. 4</b></a></li>3510 <li>downstream <a href="#rfc.iref.d.1"><b>2.3</b></a></li> 3526 3511 </ul> 3527 3512 </li> … … 3531 3516 </li> 3532 3517 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3533 <li>gateway <a href="#rfc.iref.g.13"><b>2. 4</b></a></li>3518 <li>gateway <a href="#rfc.iref.g.13"><b>2.3</b></a></li> 3534 3519 <li><tt>Grammar</tt> 3535 3520 <ul> 3536 3521 <li><tt>absolute-form</tt> <a href="#rfc.iref.g.81"><b>5.3</b></a></li> 3537 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2. 8</b></a></li>3522 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.7</b></a></li> 3538 3523 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3539 3524 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g.83"><b>5.3</b></a></li> 3540 3525 <li><tt>attribute</tt> <a href="#rfc.iref.g.58"><b>4</b></a></li> 3541 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2. 8</b></a></li>3526 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3542 3527 <li><tt>authority-form</tt> <a href="#rfc.iref.g.82"><b>5.3</b></a></li> 3543 3528 <li><tt>BWS</tt> <a href="#rfc.iref.g.40"><b>3.2.1</b></a></li> … … 3569 3554 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3570 3555 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.26"><b>3</b></a></li> 3571 <li><tt>HTTP-name</tt> <a href="#rfc.iref.g.15"><b>2. 7</b></a></li>3572 <li><tt>http-URI</tt> <a href="#rfc.iref.g.24"><b>2. 8.1</b></a></li>3573 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2. 7</b></a></li>3574 <li><tt>https-URI</tt> <a href="#rfc.iref.g.25"><b>2. 8.2</b></a></li>3556 <li><tt>HTTP-name</tt> <a href="#rfc.iref.g.15"><b>2.6</b></a></li> 3557 <li><tt>http-URI</tt> <a href="#rfc.iref.g.24"><b>2.7.1</b></a></li> 3558 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2.6</b></a></li> 3559 <li><tt>https-URI</tt> <a href="#rfc.iref.g.25"><b>2.7.2</b></a></li> 3575 3560 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.65"><b>4.1</b></a></li> 3576 3561 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> … … 3582 3567 <li><tt>origin-form</tt> <a href="#rfc.iref.g.80"><b>5.3</b></a></li> 3583 3568 <li><tt>OWS</tt> <a href="#rfc.iref.g.38"><b>3.2.1</b></a></li> 3584 <li><tt>partial-URI</tt> <a href="#rfc.iref.g.23"><b>2. 8</b></a></li>3585 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2. 8</b></a></li>3586 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2. 8</b></a></li>3569 <li><tt>partial-URI</tt> <a href="#rfc.iref.g.23"><b>2.7</b></a></li> 3570 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3571 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3587 3572 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.87"><b>5.7</b></a></li> 3588 3573 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>5.7</b></a></li> … … 3590 3575 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.4</b></a></li> 3591 3576 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b>4.1</b></a></li> 3592 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2. 8</b></a></li>3577 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3593 3578 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.51"><b>3.2.4</b></a></li> 3594 3579 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.48"><b>3.2.4</b></a></li> … … 3619 3604 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3620 3605 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.4</b></a></li> 3621 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2. 8</b></a></li>3622 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2. 8</b></a></li>3606 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3607 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3623 3608 <li><tt>value</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3624 3609 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> … … 3634 3619 <li>Header Fields 3635 3620 <ul> 3636 <li>Connection <a href="#rfc.xref.header.connection.1">2. 4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.2</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>3621 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.1</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li> 3637 3622 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3638 3623 <li>Host <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> … … 3641 3626 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> 3642 3627 <li>Upgrade <a href="#rfc.iref.h.14"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3643 <li>Via <a href="#rfc.xref.header.via.1">2. 4</a>, <a href="#rfc.iref.h.12"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>3628 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.h.12"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3644 3629 </ul> 3645 3630 </li> … … 3647 3632 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3648 3633 <li>Host header field <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> 3649 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2. 8.1</b></a></li>3650 <li>https URI scheme <a href="#rfc.iref.h.2">2. 8.2</a></li>3634 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3635 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> 3651 3636 </ul> 3652 3637 </li> 3653 3638 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 3654 <li>inbound <a href="#rfc.iref.i.2"><b>2. 4</b></a></li>3655 <li>interception proxy <a href="#rfc.iref.i.3"><b>2. 4</b></a></li>3656 <li>intermediary <a href="#rfc.iref.i.1"><b>2. 4</b></a></li>3639 <li>inbound <a href="#rfc.iref.i.2"><b>2.3</b></a></li> 3640 <li>interception proxy <a href="#rfc.iref.i.3"><b>2.3</b></a></li> 3641 <li>intermediary <a href="#rfc.iref.i.1"><b>2.3</b></a></li> 3657 3642 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2.2</a>, <a href="#ISO-8859-1"><b>10.2</b></a></li> 3658 3643 </ul> … … 3675 3660 </li> 3676 3661 <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 3677 <li><em>Nie1997</em> <a href="#rfc.xref.Nie1997.1">6.2.1</a>, <a href="#Nie1997"><b>10.2</b></a></li> 3678 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2.4</b></a></li> 3662 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2.3</b></a></li> 3679 3663 </ul> 3680 3664 </li> … … 3682 3666 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3683 3667 <li>origin-form (of request-target) <a href="#rfc.iref.o.3">5.3</a></li> 3684 <li>outbound <a href="#rfc.iref.o.2"><b>2. 4</b></a></li>3668 <li>outbound <a href="#rfc.iref.o.2"><b>2.3</b></a></li> 3685 3669 </ul> 3686 3670 </li> 3687 3671 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3688 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.2.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3689 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.4</a>, <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.2</a>, <a href="#rfc.xref.Part2.23">6.2.4</a>, <a href="#rfc.xref.Part2.24">6.3.3</a>, <a href="#rfc.xref.Part2.25">6.3.3</a>, <a href="#rfc.xref.Part2.26">6.3.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3672 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.1.2</a>, <a href="#rfc.xref.Part2.23">6.2.3</a>, <a href="#rfc.xref.Part2.24">6.3.3</a>, <a href="#rfc.xref.Part2.25">6.3.3</a>, <a href="#rfc.xref.Part2.26">6.3.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3690 3673 <li><em>Section 2</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3691 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.22">6.2. 2.2</a>, <a href="#rfc.xref.Part2.23">6.2.4</a></li>3674 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.22">6.2.1.2</a>, <a href="#rfc.xref.Part2.23">6.2.3</a></li> 3692 3675 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3693 3676 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3694 3677 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3695 <li><em>Section 4</em> <a href="#rfc.xref.Part2.4">2. 8.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li>3678 <li><em>Section 4</em> <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li> 3696 3679 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.26">6.3.3</a></li> 3697 3680 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.24">6.3.3</a></li> 3698 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.3">2. 4</a></li>3681 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3699 3682 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.27">6.4</a></li> 3700 3683 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.30">8.6</a></li> … … 3722 3705 </ul> 3723 3706 </li> 3724 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2. 4</a>, <a href="#rfc.xref.Part6.3">2.5</a>, <a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.8</a>, <a href="#rfc.xref.Part6.8">5.8</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>3725 <li><em>Section 2</em> <a href="#rfc.xref.Part6.3">2. 5</a></li>3707 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.8</a>, <a href="#rfc.xref.Part6.8">5.8</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 3708 <li><em>Section 2</em> <a href="#rfc.xref.Part6.3">2.4</a></li> 3726 3709 <li><em>Section 3</em> <a href="#rfc.xref.Part6.5">3.4</a></li> 3727 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.4">2. 8.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li>3710 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li> 3728 3711 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.7">5.8</a></li> 3729 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6.2">2. 4</a>, <a href="#rfc.xref.Part6.8">5.8</a></li>3712 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5.8</a></li> 3730 3713 </ul> 3731 3714 </li> 3732 3715 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">1</a>, <a href="#Part7"><b>10.1</b></a></li> 3733 <li>proxy <a href="#rfc.iref.p.1"><b>2. 4</b></a></li>3716 <li>proxy <a href="#rfc.iref.p.1"><b>2.3</b></a></li> 3734 3717 </ul> 3735 3718 </li> … … 3738 3721 <li>request <a href="#rfc.iref.r.2"><b>2.1</b></a></li> 3739 3722 <li>request-target <a href="#rfc.iref.r.6">3.1.1</a></li> 3740 <li>resource <a href="#rfc.iref.r.5"><b>2. 8</b></a></li>3723 <li>resource <a href="#rfc.iref.r.5"><b>2.7</b></a></li> 3741 3724 <li>response <a href="#rfc.iref.r.3"><b>2.1</b></a></li> 3742 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2. 4</b></a></li>3743 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2. 4</a>, <a href="#RFC1919"><b>10.2</b></a></li>3744 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2. 7</a>, <a href="#rfc.xref.RFC1945.2">9</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.3">A</a></li>3725 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2.3</b></a></li> 3726 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>10.2</b></a></li> 3727 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#rfc.xref.RFC1945.2">9</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.3">A</a></li> 3745 3728 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.5</a>, <a href="#RFC1950"><b>10.1</b></a></li> 3746 3729 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.5</a>, <a href="#RFC1951"><b>10.1</b></a></li> … … 3751 3734 </li> 3752 3735 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3753 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2. 7</a>, <a href="#rfc.xref.RFC2068.3">6.2.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>3754 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.2. 2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>3736 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul> 3737 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.2.1.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li> 3755 3738 </ul> 3756 3739 </li> 3757 3740 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 3758 3741 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li> 3759 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2. 7</a>, <a href="#rfc.xref.RFC2616.3">5.8</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">D.1</a><ul>3742 <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">5.8</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">D.1</a><ul> 3760 3743 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616.3">5.8</a></li> 3761 3744 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.5">9</a></li> … … 3766 3749 </ul> 3767 3750 </li> 3768 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2. 8.2</a>, <a href="#RFC2818"><b>10.2</b></a></li>3751 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>10.2</b></a></li> 3769 3752 <li><em>RFC2965</em> <a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>10.2</b></a></li> 3770 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2. 4</a>, <a href="#RFC3040"><b>10.2</b></a></li>3753 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>10.2</b></a></li> 3771 3754 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">7.1</a>, <a href="#RFC3864"><b>10.2</b></a></li> 3772 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#rfc.xref.RFC3986.2">2. 8</a>, <a href="#rfc.xref.RFC3986.3">2.8</a>, <a href="#rfc.xref.RFC3986.4">2.8</a>, <a href="#rfc.xref.RFC3986.5">2.8</a>, <a href="#rfc.xref.RFC3986.6">2.8</a>, <a href="#rfc.xref.RFC3986.7">2.8</a>, <a href="#rfc.xref.RFC3986.8">2.8</a>, <a href="#rfc.xref.RFC3986.9">2.8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a>, <a href="#rfc.xref.RFC3986.11">2.8</a>, <a href="#rfc.xref.RFC3986.12">2.8</a>, <a href="#rfc.xref.RFC3986.13">2.8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a>, <a href="#rfc.xref.RFC3986.15">2.8.1</a>, <a href="#rfc.xref.RFC3986.16">2.8.3</a>, <a href="#rfc.xref.RFC3986.17">2.8.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul>3773 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2. 8.3</a></li>3774 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2. 8</a></li>3775 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2. 8.1</a></li>3776 <li><em>Section 3.2.2</em> <a href="#rfc.xref.RFC3986.13">2. 8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a></li>3777 <li><em>Section 3.2.3</em> <a href="#rfc.xref.RFC3986.11">2. 8</a></li>3778 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC3986.9">2. 8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a></li>3779 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC3986.12">2. 8</a></li>3755 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">2.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">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul> 3756 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.7.3</a></li> 3757 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.7</a></li> 3758 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2.7.1</a></li> 3759 <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> 3760 <li><em>Section 3.2.3</em> <a href="#rfc.xref.RFC3986.11">2.7</a></li> 3761 <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> 3762 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC3986.12">2.7</a></li> 3780 3763 <li><em>Section 3.5</em> <a href="#rfc.xref.RFC3986.18">5.1</a></li> 3781 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2. 8</a></li>3782 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2. 8</a></li>3783 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2. 8</a></li>3784 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2. 8.3</a></li>3764 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3765 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</a></li> 3766 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2.7</a></li> 3767 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2.7.3</a></li> 3785 3768 </ul> 3786 3769 </li> … … 3788 3771 <li><em>RFC4288</em> <a href="#rfc.xref.RFC4288.1">7.3</a>, <a href="#RFC4288"><b>10.2</b></a></li> 3789 3772 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li> 3790 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2. 4</a>, <a href="#RFC4559"><b>10.2</b></a></li>3773 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li> 3791 3774 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a>, <a href="#RFC5226"><b>10.2</b></a><ul> 3792 3775 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a></li> … … 3801 3784 </ul> 3802 3785 </li> 3803 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1">2. 8.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>10.2</b></a></li>3786 <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>10.2</b></a></li> 3804 3787 </ul> 3805 3788 </li> … … 3807 3790 <li>sender <a href="#rfc.iref.s.3"><b>2.1</b></a></li> 3808 3791 <li>server <a href="#rfc.iref.s.1"><b>2.1</b></a></li> 3809 <li><em>Spe</em> <a href="#rfc.xref.Spe.1">6.2.1</a>, <a href="#Spe"><b>10.2</b></a></li>3810 3792 <li>spider <a href="#rfc.iref.s.2"><b>2.1</b></a></li> 3811 3793 </ul> … … 3815 3797 <li>target URI <a href="#rfc.iref.t.8"><b>5.1</b></a></li> 3816 3798 <li>TE header field <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.1</a>, <a href="#rfc.iref.t.6"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">7.1</a></li> 3817 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.2.1</a>, <a href="#Tou1998"><b>10.2</b></a></li>3818 3799 <li>Trailer header field <a href="#rfc.iref.t.5"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li> 3819 3800 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> 3820 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2. 4</b></a></li>3821 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2. 4</b></a></li>3822 <li>tunnel <a href="#rfc.iref.t.2"><b>2. 4</b></a></li>3801 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.3</b></a></li> 3802 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.3</b></a></li> 3803 <li>tunnel <a href="#rfc.iref.t.2"><b>2.3</b></a></li> 3823 3804 </ul> 3824 3805 </li> 3825 3806 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3826 3807 <li>Upgrade header field <a href="#rfc.iref.u.5"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3827 <li>upstream <a href="#rfc.iref.u.2"><b>2. 4</b></a></li>3808 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3828 3809 <li>URI scheme 3829 3810 <ul> 3830 <li>http <a href="#rfc.iref.u.3"><b>2. 8.1</b></a></li>3831 <li>https <a href="#rfc.iref.u.4">2. 8.2</a></li>3811 <li>http <a href="#rfc.iref.u.3"><b>2.7.1</b></a></li> 3812 <li>https <a href="#rfc.iref.u.4">2.7.2</a></li> 3832 3813 </ul> 3833 3814 </li> … … 3837 3818 </li> 3838 3819 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3839 <li>Via header field <a href="#rfc.xref.header.via.1">2. 4</a>, <a href="#rfc.iref.v.1"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>3820 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3840 3821 </ul> 3841 3822 </li>
Note: See TracChangeset
for help on using the changeset viewer.