Changeset 1762 for draft-ietf-httpbis
- Timestamp:
- 13/07/12 08:57:46 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1760 r1762 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 2, 2013";451 content: "Expires January 14, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 1">493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-13"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 1 2, 2013</td>525 <td class="left">Expires: January 14, 2013</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">July 1 1, 2012</td>530 <td class="right">July 13, 2012</td> 531 531 </tr> 532 532 </tbody> … … 545 545 </p> 546 546 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 547 <p>Discussion of this draft ought to take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived 548 at <<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>>. 547 <p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at <<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>>. 549 548 </p> 550 549 <p>The current issues list is at <<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>> and related documents (including fancy diffs) can be found at <<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>>. … … 561 560 in progress”. 562 561 </p> 563 <p>This Internet-Draft will expire on January 1 2, 2013.</p>562 <p>This Internet-Draft will expire on January 14, 2013.</p> 564 563 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 565 564 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 586 585 <li>2. <a href="#architecture">Architecture</a><ul> 587 586 <li>2.1 <a href="#operation">Client/Server Messaging</a></li> 588 <li>2.2 <a href="#transport-independence">Connections and Transport Independence</a></li> 589 <li>2.3 <a href="#intermediaries">Intermediaries</a></li> 590 <li>2.4 <a href="#caches">Caches</a></li> 591 <li>2.5 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 592 <li>2.6 <a href="#http.version">Protocol Versioning</a></li> 593 <li>2.7 <a href="#uri">Uniform Resource Identifiers</a><ul> 594 <li>2.7.1 <a href="#http.uri">http URI scheme</a></li> 595 <li>2.7.2 <a href="#https.uri">https URI scheme</a></li> 596 <li>2.7.3 <a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 587 <li>2.2 <a href="#implementation-diversity">Implementation Diversity</a></li> 588 <li>2.3 <a href="#transport-independence">Connections and Transport Independence</a></li> 589 <li>2.4 <a href="#intermediaries">Intermediaries</a></li> 590 <li>2.5 <a href="#caches">Caches</a></li> 591 <li>2.6 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 592 <li>2.7 <a href="#http.version">Protocol Versioning</a></li> 593 <li>2.8 <a href="#uri">Uniform Resource Identifiers</a><ul> 594 <li>2.8.1 <a href="#http.uri">http URI scheme</a></li> 595 <li>2.8.2 <a href="#https.uri">https URI scheme</a></li> 596 <li>2.8.3 <a href="#uri.comparison">http and https URI Normalization and Comparison</a></li> 597 597 </ul> 598 598 </li> … … 811 811 <div id="rfc.iref.s.3"></div> 812 812 <div id="rfc.iref.r.1"></div> 813 <p id="rfc.section.2.1.p.2"> Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The814 same programmight act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the813 <p id="rfc.section.2.1.p.2">The terms client and server refer only to the roles that these programs perform for a particular connection. The same program 814 might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the 815 815 term "<dfn>origin server</dfn>" to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term 816 816 "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message. 817 817 </p> 818 <div class="note" id="rfc.section.2.1.p.3"> 819 <p> <b>Note:</b> The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and 820 for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the 821 case of security or privacy options) and also those where the software agent can act autonomously. 822 </p> 823 </div> 824 <p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In 818 <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In 825 819 the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and 826 820 the origin server (O). … … 832 826 <div id="rfc.iref.r.2"></div> 833 827 <div id="rfc.iref.r.3"></div> 834 <p id="rfc.section.2.1.p. 6">A client sends an HTTP request to theserver in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request Line">Section 3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, 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>).835 </p> 836 <p id="rfc.section.2.1.p. 7">A server responds to theclient's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason828 <p id="rfc.section.2.1.p.5">A client sends an HTTP request to a server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request Line">Section 3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, 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>). 829 </p> 830 <p id="rfc.section.2.1.p.6">A server responds to a client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason 837 831 phrase (<a href="#status.line" title="Status Line">Section 3.1.2</a>), possibly followed by MIME-like header fields containing server information, resource metadata, and representation metadata 838 832 (<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>). 839 833 </p> 840 <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>834 <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 841 835 <div id="rfc.figure.u.2"></div> 842 836 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 … … 857 851 858 852 <span id="exbody">Hello World! 859 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2> 860 <p id="rfc.section.2.2.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable 853 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="implementation-diversity" href="#implementation-diversity">Implementation Diversity</a></h2> 854 <p id="rfc.section.2.2.p.1">When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers 855 and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household 856 appliances, stereos, scales, software/firmware updaters, command-line programs, mobile apps, and communication devices in 857 a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking 858 components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms. 859 </p> 860 <p id="rfc.section.2.2.p.2">The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of 861 a request. In many cases, a user agent is installed or configured to run in the background and save its results for later 862 inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically 863 given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph. 864 </p> 865 <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that we cannot assume the user agent can make interactive suggestions to a user 866 or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting 867 of errors to the user, it is acceptable for such reporting to only be visible in an error console or log file. Likewise, requirements 868 that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, run-time 869 options, or simply not proceeding with the unsafe action. 870 </p> 871 <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> 872 <p id="rfc.section.2.3.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable 861 873 transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request 862 874 and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. 863 875 </p> 864 <p id="rfc.section.2. 2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target URI865 (<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. 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 use876 <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 URI 877 (<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 use 866 878 a proxy via some other connection port or protocol instead of using the defaults. 867 879 </p> 868 <p id="rfc.section.2. 2.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section 6.3</a>.880 <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.3</a>. 869 881 </p> 870 882 <div id="rfc.iref.i.1"></div> 871 <h2 id="rfc.section.2. 3"><a href="#rfc.section.2.3">2.3</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>872 <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 of883 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 884 <p id="rfc.section.2.4.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of 873 885 HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, 874 886 switching behavior based on the nature of each request. … … 877 889 <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b> 878 890 < < < < 879 </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 response891 </pre><p id="rfc.section.2.4.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response 880 892 message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply 881 893 only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along … … 884 896 at the same time that it is handling A's request. 885 897 </p> 886 <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.898 <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. 887 899 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. 888 900 </p> 889 <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 requests901 <p id="rfc.section.2.4.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests 890 902 for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations 891 903 are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely … … 893 905 for the sake of security, annotation services, or shared caching. 894 906 </p> 895 <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,907 <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, 896 908 beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original 897 909 sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared … … 901 913 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.2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 902 914 </p> 903 <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 underlying915 <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 underlying 904 916 server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance 905 917 through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. 906 918 </p> 907 <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 requirements919 <p id="rfc.section.2.4.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements 908 920 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 909 921 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 910 922 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 6.2</a>) header fields for both connections. 911 923 </p> 912 <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 party924 <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party 913 925 to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both 914 926 ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 915 927 when transport-layer security is used to establish private communication through a shared firewall proxy. 916 928 </p> 917 <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 also929 <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 also 918 930 intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the 919 931 knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems … … 923 935 and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack. 924 936 </p> 925 <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 implementations937 <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 implementations 926 938 depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple 927 939 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 … … 929 941 </p> 930 942 <div id="rfc.iref.c.4"></div> 931 <h2 id="rfc.section.2. 4"><a href="#rfc.section.2.4">2.4</a> <a id="caches" href="#caches">Caches</a></h2>932 <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.943 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="caches" href="#caches">Caches</a></h2> 944 <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. 933 945 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 934 946 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. 935 947 </p> 936 <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 cached948 <p id="rfc.section.2.5.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached 937 949 response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response 938 950 from O (via C) for a request which has not been cached by UA or A. … … 941 953 <b>UA</b> =========== <b>A</b> =========== <b>B</b> - - - - - - <b>C</b> - - - - - - <b>O</b> 942 954 < < 943 </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 response955 </pre><p id="rfc.section.2.5.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 944 956 is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 945 957 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.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 946 958 </p> 947 <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 and959 <p id="rfc.section.2.5.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and 948 960 inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems 949 961 that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so 950 962 on. 951 963 </p> 952 <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>953 <p id="rfc.section.2. 5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP964 <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> 965 <p id="rfc.section.2.6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 954 966 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 955 967 or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send" 956 968 where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream. 957 969 </p> 958 <p id="rfc.section.2. 5.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes970 <p id="rfc.section.2.6.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 959 971 in HTTP. 960 972 </p> 961 <p id="rfc.section.2. 5.p.3">A sender <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 applicable973 <p id="rfc.section.2.6.p.3">A sender <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 962 974 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 963 975 to the recipient's role. 964 976 </p> 965 <p id="rfc.section.2. 5.p.4">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 mechanisms977 <p id="rfc.section.2.6.p.4">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 966 978 except when they have a direct impact on security, since different applications of the protocol require different error handling 967 979 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 968 980 to be dangerous. 969 981 </p> 970 <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>971 <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".982 <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> 983 <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". 972 984 The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's 973 985 corresponding specification of HTTP. 974 986 </p> 975 <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>987 <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> 976 988 <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> 977 989 <a href="#http.version" class="smpl">HTTP-name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 978 </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 ("major990 </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 ("major 979 991 version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version 980 992 to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's … … 982 994 the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). 983 995 </p> 984 <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.0996 <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.0 985 997 message if all of the newer features are ignored. This specification places recipient-version requirements on some new features 986 998 so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt 987 999 of a message, that the recipient supports HTTP/1.1. 988 1000 </p> 989 <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 default1001 <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 default 990 1002 behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 991 1003 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. 992 1004 </p> 993 <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 interpretation1005 <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 interpretation 994 1006 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 995 1007 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. 996 1008 </p> 997 <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 version1009 <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 version 998 1010 to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without 999 1011 rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version 1000 1012 to determine what features are safe to use for later communication with that sender. 1001 1013 </p> 1002 <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 higher1014 <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 higher 1003 1015 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. 1004 1016 </p> 1005 <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 after1017 <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 after 1006 1018 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. 1007 1019 </p> 1008 <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 than1020 <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 than 1009 1021 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 1010 1022 Supported)</a> response if it cannot send a response using the major version used in the client's request. 1011 1023 </p> 1012 <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 HTTP1024 <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 HTTP 1013 1025 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 1014 1026 number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the 1015 1027 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. 1016 1028 </p> 1017 <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 syntax1029 <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 syntax 1018 1030 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1019 1031 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented … … 1021 1033 </p> 1022 1034 <div id="rfc.iref.r.5"></div> 1023 <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>1024 <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,1035 <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> 1036 <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, 1025 1037 and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to 1026 1038 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>. 1027 1039 </p> 1028 <p id="rfc.section.2. 7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",1040 <p id="rfc.section.2.8.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", 1029 1041 "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. 1030 1042 </p> … … 1040 1052 1041 1053 <a href="#uri" class="smpl">partial-URI</a> = relative-part [ "?" query ] 1042 </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 allows1054 </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 allows 1043 1055 any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, 1044 1056 or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request 1045 1057 URI (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>). 1046 1058 </p> 1047 <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>1059 <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> 1048 1060 <div id="rfc.iref.h.1"></div> 1049 1061 <div id="rfc.iref.u.3"></div> 1050 <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 hierarchical1062 <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 hierarchical 1051 1063 namespace governed by a potential HTTP origin server listening for TCP connections on a given port. 1052 1064 </p> 1053 1065 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.23"></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> ] 1054 </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 an1066 </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 an 1055 1067 identifier for a potential resource within that origin server's name space. 1056 1068 </p> 1057 <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 indicated1069 <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 indicated 1058 1070 TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient 1059 1071 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 1060 1072 port for WWW services). 1061 1073 </p> 1062 <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.1074 <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. 1063 1075 The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening 1064 1076 to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish … … 1066 1078 authority to determine which names are valid and how they might be used. 1067 1079 </p> 1068 <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,1080 <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, 1069 1081 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.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1070 1082 </p> 1071 <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 name1083 <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 name 1072 1084 delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol 1073 1085 would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require … … 1075 1087 — it is only the authoritative interface used for mapping the namespace that is specific to TCP. 1076 1088 </p> 1077 <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 internal1089 <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 internal 1078 1090 configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, 1079 1091 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 … … 1081 1093 is being used to obscure the authority for the sake of phishing attacks. 1082 1094 </p> 1083 <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>1095 <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> 1084 1096 <div id="rfc.iref.h.2"></div> 1085 1097 <div id="rfc.iref.u.4"></div> 1086 <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 hierarchical1098 <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 hierarchical 1087 1099 namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. 1088 1100 </p> 1089 <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 default1101 <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 default 1090 1102 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request. 1091 1103 </p> 1092 1104 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.24"></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> ] 1093 </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 HTTP1105 </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 HTTP 1094 1106 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.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1095 1107 </p> 1096 <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 identifiers1108 <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 identifiers 1097 1109 indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered 1098 1110 to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the 1099 1111 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. 1100 1112 </p> 1101 <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>.1102 </p> 1103 <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>1104 <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 to1113 <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>. 1114 </p> 1115 <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> 1116 <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 to 1105 1117 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. 1106 1118 </p> 1107 <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 empty1119 <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 empty 1108 1120 path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme 1109 1121 and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. 1110 1122 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. 1111 1123 </p> 1112 <p id="rfc.section.2. 7.3.p.3">For example, the following three URIs are equivalent:</p>1124 <p id="rfc.section.2.8.3.p.3">For example, the following three URIs are equivalent:</p> 1113 1125 <div id="rfc.figure.u.10"></div><pre class="text"> http://example.com:80/~smith/home.html 1114 1126 http://EXAMPLE.com/%7Esmith/home.html … … 1428 1440 have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. 1429 1441 </p> 1430 <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only 1431 within the "message/external-body" media-type. 1432 </p> 1433 <p id="rfc.section.3.3.2.p.7">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of 1442 <p id="rfc.section.3.3.2.p.6">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of 1434 1443 an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Protocol Element Size Overflows">Section 8.6</a>). 1435 1444 </p> 1436 <p id="rfc.section.3.3.2.p. 8">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing1445 <p id="rfc.section.3.3.2.p.7">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing 1437 1446 a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields 1438 1447 have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing 1439 1448 that decimal value prior to determining the message body length. 1440 1449 </p> 1450 <div class="note" id="rfc.section.3.3.2.p.8"> 1451 <p> <b>Note:</b> HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional 1452 field used only within the "message/external-body" media-type. 1453 </p> 1454 </div> 1441 1455 <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="message.body.length" href="#message.body.length">Message Body Length</a></h3> 1442 1456 <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p> … … 1743 1757 </p> 1744 1758 <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 1745 are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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 "target resource", which a user agent would resolve to its absolute form in order1759 are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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 "target resource", which a user agent would resolve to its absolute form in order 1746 1760 to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment 1747 1761 identifiers are reserved 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>). … … 1762 1776 connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and 1763 1777 defined by its associated specification, similar to how this specification defines origin server access for resolution of 1764 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.1778 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. 1765 1779 </p> 1766 1780 <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> … … 1828 1842 is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line. 1829 1843 </p> 1830 <div id="rfc.figure.u.53"></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>1844 <div id="rfc.figure.u.53"></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> 1831 1845 </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 1832 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.1846 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. 1833 1847 </p> 1834 1848 <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> … … 1888 1902 </p> 1889 1903 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="intermediary.forwarding" href="#intermediary.forwarding">Intermediary Forwarding</a></h2> 1890 <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 used1904 <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 used 1891 1905 to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has 1892 1906 characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can … … 2249 2263 </p> 2250 2264 <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2251 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 defined2265 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 defined 2252 2266 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. 2253 2267 </p> … … 2374 2388 <td class="left">http</td> 2375 2389 <td class="left">Hypertext Transfer Protocol</td> 2376 <td class="left"><a href="#http.uri" title="http URI scheme">Section 2. 7.1</a></td>2390 <td class="left"><a href="#http.uri" title="http URI scheme">Section 2.8.1</a></td> 2377 2391 </tr> 2378 2392 <tr> 2379 2393 <td class="left">https</td> 2380 2394 <td class="left">Hypertext Transfer Protocol Secure</td> 2381 <td class="left"><a href="#https.uri" title="https URI scheme">Section 2. 7.2</a></td>2395 <td class="left"><a href="#https.uri" title="https URI scheme">Section 2.8.2</a></td> 2382 2396 </tr> 2383 2397 </tbody> … … 2595 2609 <td class="left">Hypertext Transfer Protocol</td> 2596 2610 <td class="left">any DIGIT.DIGIT (e.g, "2.0")</td> 2597 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2. 6</a></td>2611 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2.7</a></td> 2598 2612 </tr> 2599 2613 </tbody> … … 2969 2983 <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> 2970 2984 <p id="rfc.section.A.2.p.1">Clarify that the string "HTTP" in the HTTP-version ABFN production is case sensitive. Restrict the version numbers to be single 2971 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>)2985 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>) 2972 2986 </p> 2973 2987 <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 … … 3547 3561 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3548 3562 <li>absolute-form (of request-target) <a href="#rfc.iref.a.2">5.3</a></li> 3549 <li>accelerator <a href="#rfc.iref.a.1"><b>2. 3</b></a></li>3563 <li>accelerator <a href="#rfc.iref.a.1"><b>2.4</b></a></li> 3550 3564 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>7.3.2</b></a></li> 3551 3565 <li>asterisk-form (of request-target) <a href="#rfc.iref.a.4">5.3</a></li> … … 3558 3572 </li> 3559 3573 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3560 <li>cache <a href="#rfc.iref.c.4"><b>2. 4</b></a></li>3561 <li>cacheable <a href="#rfc.iref.c.5"><b>2. 4</b></a></li>3562 <li>captive portal <a href="#rfc.iref.c.3"><b>2. 3</b></a></li>3574 <li>cache <a href="#rfc.iref.c.4"><b>2.5</b></a></li> 3575 <li>cacheable <a href="#rfc.iref.c.5"><b>2.5</b></a></li> 3576 <li>captive portal <a href="#rfc.iref.c.3"><b>2.4</b></a></li> 3563 3577 <li>chunked (Coding Format) <a href="#rfc.iref.c.7">4.1</a></li> 3564 3578 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> … … 3573 3587 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3574 3588 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3575 <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.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3589 <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.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3576 3590 <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">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li> 3577 3591 </ul> … … 3579 3593 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3580 3594 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">4.2.2</a></li> 3581 <li>downstream <a href="#rfc.iref.d.1"><b>2. 3</b></a></li>3595 <li>downstream <a href="#rfc.iref.d.1"><b>2.4</b></a></li> 3582 3596 </ul> 3583 3597 </li> … … 3587 3601 </li> 3588 3602 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3589 <li>gateway <a href="#rfc.iref.g.13"><b>2. 3</b></a></li>3603 <li>gateway <a href="#rfc.iref.g.13"><b>2.4</b></a></li> 3590 3604 <li><tt>Grammar</tt> 3591 3605 <ul> 3592 3606 <li><tt>absolute-form</tt> <a href="#rfc.iref.g.81"><b>5.3</b></a></li> 3593 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2. 7</b></a></li>3607 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.8</b></a></li> 3594 3608 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3595 3609 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g.83"><b>5.3</b></a></li> 3596 3610 <li><tt>attribute</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3597 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2. 7</b></a></li>3611 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.8</b></a></li> 3598 3612 <li><tt>authority-form</tt> <a href="#rfc.iref.g.82"><b>5.3</b></a></li> 3599 3613 <li><tt>BWS</tt> <a href="#rfc.iref.g.39"><b>3.2.1</b></a></li> … … 3625 3639 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3626 3640 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.25"><b>3</b></a></li> 3627 <li><tt>HTTP-name</tt> <a href="#rfc.iref.g.15"><b>2. 6</b></a></li>3628 <li><tt>http-URI</tt> <a href="#rfc.iref.g.23"><b>2. 7.1</b></a></li>3629 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2. 6</b></a></li>3630 <li><tt>https-URI</tt> <a href="#rfc.iref.g.24"><b>2. 7.2</b></a></li>3641 <li><tt>HTTP-name</tt> <a href="#rfc.iref.g.15"><b>2.7</b></a></li> 3642 <li><tt>http-URI</tt> <a href="#rfc.iref.g.23"><b>2.8.1</b></a></li> 3643 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2.7</b></a></li> 3644 <li><tt>https-URI</tt> <a href="#rfc.iref.g.24"><b>2.8.2</b></a></li> 3631 3645 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.64"><b>4.1</b></a></li> 3632 3646 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> … … 3638 3652 <li><tt>origin-form</tt> <a href="#rfc.iref.g.80"><b>5.3</b></a></li> 3639 3653 <li><tt>OWS</tt> <a href="#rfc.iref.g.37"><b>3.2.1</b></a></li> 3640 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2. 7</b></a></li>3641 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2. 7</b></a></li>3654 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.8</b></a></li> 3655 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.8</b></a></li> 3642 3656 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.89"><b>6.2</b></a></li> 3643 3657 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.90"><b>6.2</b></a></li> … … 3645 3659 <li><tt>qdtext</tt> <a href="#rfc.iref.g.45"><b>3.2.4</b></a></li> 3646 3660 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a></li> 3647 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2. 7</b></a></li>3661 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.8</b></a></li> 3648 3662 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.50"><b>3.2.4</b></a></li> 3649 3663 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.47"><b>3.2.4</b></a></li> … … 3675 3689 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3676 3690 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.5</b></a></li> 3677 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2. 7</b></a></li>3678 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2. 7</b></a></li>3691 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.8</b></a></li> 3692 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.8</b></a></li> 3679 3693 <li><tt>value</tt> <a href="#rfc.iref.g.58"><b>4</b></a></li> 3680 3694 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> … … 3690 3704 <li>Header Fields 3691 3705 <ul> 3692 <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.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3706 <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.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3693 3707 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li> 3694 3708 <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> … … 3697 3711 <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> 3698 3712 <li>Upgrade <a href="#rfc.iref.h.14"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3699 <li>Via <a href="#rfc.xref.header.via.1">2. 3</a>, <a href="#rfc.iref.h.13"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>3713 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.h.13"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3700 3714 </ul> 3701 3715 </li> … … 3703 3717 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3704 3718 <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> 3705 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2. 7.1</b></a></li>3706 <li>https URI scheme <a href="#rfc.iref.h.2">2. 7.2</a></li>3719 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.8.1</b></a></li> 3720 <li>https URI scheme <a href="#rfc.iref.h.2">2.8.2</a></li> 3707 3721 </ul> 3708 3722 </li> 3709 3723 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 3710 <li>inbound <a href="#rfc.iref.i.2"><b>2. 3</b></a></li>3711 <li>interception proxy <a href="#rfc.iref.i.3"><b>2. 3</b></a></li>3712 <li>intermediary <a href="#rfc.iref.i.1"><b>2. 3</b></a></li>3724 <li>inbound <a href="#rfc.iref.i.2"><b>2.4</b></a></li> 3725 <li>interception proxy <a href="#rfc.iref.i.3"><b>2.4</b></a></li> 3726 <li>intermediary <a href="#rfc.iref.i.1"><b>2.4</b></a></li> 3713 3727 <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.1</b></a></li> 3714 3728 </ul> … … 3732 3746 <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 3733 3747 <li><em>Nie1997</em> <a href="#rfc.xref.Nie1997.1">6.3.1</a>, <a href="#Nie1997"><b>10.2</b></a></li> 3734 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2. 3</b></a></li>3748 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2.4</b></a></li> 3735 3749 </ul> 3736 3750 </li> … … 3738 3752 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3739 3753 <li>origin-form (of request-target) <a href="#rfc.iref.o.3">5.3</a></li> 3740 <li>outbound <a href="#rfc.iref.o.2"><b>2. 3</b></a></li>3754 <li>outbound <a href="#rfc.iref.o.2"><b>2.4</b></a></li> 3741 3755 </ul> 3742 3756 </li> 3743 3757 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3744 3758 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3745 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2. 3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3759 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.4</a>, <a href="#rfc.xref.Part2.3">2.8.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3746 3760 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1</a></li> 3747 3761 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a></li> … … 3749 3763 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.12">5.3</a></li> 3750 3764 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3751 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2. 7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li>3765 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2.8.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li> 3752 3766 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li> 3753 3767 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.20">6.4.3</a></li> 3754 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.2">2. 3</a></li>3768 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.2">2.4</a></li> 3755 3769 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.23">6.5</a></li> 3756 3770 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.26">8.6</a></li> … … 3773 3787 </ul> 3774 3788 </li> 3775 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2. 3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>3776 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2. 4</a></li>3789 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.8.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 3790 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2.5</a></li> 3777 3791 <li><em>Section 3</em> <a href="#rfc.xref.Part6.4">3.4</a></li> 3778 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.3">2. 7.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li>3792 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.3">2.8.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li> 3779 3793 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.6">5.6.2</a></li> 3780 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6.1">2. 3</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li>3794 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li> 3781 3795 </ul> 3782 3796 </li> … … 3786 3800 </ul> 3787 3801 </li> 3788 <li>proxy <a href="#rfc.iref.p.1"><b>2. 3</b></a></li>3802 <li>proxy <a href="#rfc.iref.p.1"><b>2.4</b></a></li> 3789 3803 </ul> 3790 3804 </li> … … 3793 3807 <li>request <a href="#rfc.iref.r.2"><b>2.1</b></a></li> 3794 3808 <li>request-target <a href="#rfc.iref.r.6">3.1.1</a></li> 3795 <li>resource <a href="#rfc.iref.r.5"><b>2. 7</b></a></li>3809 <li>resource <a href="#rfc.iref.r.5"><b>2.8</b></a></li> 3796 3810 <li>response <a href="#rfc.iref.r.3"><b>2.1</b></a></li> 3797 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2. 3</b></a></li>3798 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2. 3</a>, <a href="#RFC1919"><b>10.2</b></a></li>3799 <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>3811 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2.4</b></a></li> 3812 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>10.2</b></a></li> 3813 <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> 3800 3814 <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> 3801 3815 <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> … … 3806 3820 </li> 3807 3821 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3808 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2. 6</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul>3822 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.7</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul> 3809 3823 <li><em>Section 19.7.1.1</em> <a href="#rfc.xref.RFC2068.3">5.6.1</a></li> 3810 3824 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a></li> … … 3813 3827 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 3814 3828 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">§</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#rfc.xref.RFC2145.3">9</a>, <a href="#RFC2145"><b>10.2</b></a></li> 3815 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2. 6</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">C.1</a><ul>3829 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.7</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">C.1</a><ul> 3816 3830 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.5">9</a></li> 3817 3831 </ul> … … 3821 3835 </ul> 3822 3836 </li> 3823 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2. 7.2</a>, <a href="#RFC2818"><b>10.2</b></a></li>3837 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2.8.2</a>, <a href="#RFC2818"><b>10.2</b></a></li> 3824 3838 <li><em>RFC2965</em> <a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>10.2</b></a></li> 3825 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2. 3</a>, <a href="#RFC3040"><b>10.2</b></a></li>3839 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>10.2</b></a></li> 3826 3840 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">7.1</a>, <a href="#RFC3864"><b>10.2</b></a></li> 3827 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2. 7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul>3828 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2. 7.3</a></li>3829 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2. 7</a></li>3830 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2. 7.1</a></li>3831 <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>3832 <li><em>Section 3.2.3</em> <a href="#rfc.xref.RFC3986.11">2. 7</a></li>3833 <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>3834 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC3986.12">2. 7</a></li>3841 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">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> 3842 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.8.3</a></li> 3843 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.8</a></li> 3844 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2.8.1</a></li> 3845 <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> 3846 <li><em>Section 3.2.3</em> <a href="#rfc.xref.RFC3986.11">2.8</a></li> 3847 <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> 3848 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC3986.12">2.8</a></li> 3835 3849 <li><em>Section 3.5</em> <a href="#rfc.xref.RFC3986.18">5.1</a></li> 3836 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2. 7</a></li>3837 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2. 7</a></li>3838 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2. 7</a></li>3839 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2. 7.3</a></li>3850 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.8</a></li> 3851 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.8</a></li> 3852 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2.8</a></li> 3853 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2.8.3</a></li> 3840 3854 </ul> 3841 3855 </li> … … 3843 3857 <li><em>RFC4288</em> <a href="#rfc.xref.RFC4288.1">7.3</a>, <a href="#RFC4288"><b>10.2</b></a></li> 3844 3858 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li> 3845 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2. 3</a>, <a href="#RFC4559"><b>10.2</b></a></li>3859 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.4</a>, <a href="#RFC4559"><b>10.2</b></a></li> 3846 3860 <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> 3847 3861 <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> … … 3856 3870 </ul> 3857 3871 </li> 3858 <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>3872 <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> 3859 3873 </ul> 3860 3874 </li> … … 3873 3887 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li> 3874 3888 <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> 3875 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2. 3</b></a></li>3876 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2. 3</b></a></li>3877 <li>tunnel <a href="#rfc.iref.t.2"><b>2. 3</b></a></li>3889 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.4</b></a></li> 3890 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.4</b></a></li> 3891 <li>tunnel <a href="#rfc.iref.t.2"><b>2.4</b></a></li> 3878 3892 </ul> 3879 3893 </li> 3880 3894 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3881 3895 <li>Upgrade header field <a href="#rfc.iref.u.5"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3882 <li>upstream <a href="#rfc.iref.u.2"><b>2. 3</b></a></li>3896 <li>upstream <a href="#rfc.iref.u.2"><b>2.4</b></a></li> 3883 3897 <li>URI scheme 3884 3898 <ul> 3885 <li>http <a href="#rfc.iref.u.3"><b>2. 7.1</b></a></li>3886 <li>https <a href="#rfc.iref.u.4">2. 7.2</a></li>3899 <li>http <a href="#rfc.iref.u.3"><b>2.8.1</b></a></li> 3900 <li>https <a href="#rfc.iref.u.4">2.8.2</a></li> 3887 3901 </ul> 3888 3902 </li> … … 3892 3906 </li> 3893 3907 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3894 <li>Via header field <a href="#rfc.xref.header.via.1">2. 3</a>, <a href="#rfc.iref.v.1"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>3908 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.v.1"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3895 3909 </ul> 3896 3910 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1760 r1762 145 145 <note title="Editorial Note (To be removed by RFC Editor)"> 146 146 <t> 147 Discussion of this draft ought to takeplace on the HTTPBIS working group147 Discussion of this draft takes place on the HTTPBIS working group 148 148 mailing list (ietf-http-wg@w3.org), which is archived at 149 149 <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>. … … 303 303 <iref primary="true" item="recipient"/> 304 304 <t> 305 Note that the terms client and server refer only to the roles that305 The terms client and server refer only to the roles that 306 306 these programs perform for a particular connection. The same program 307 307 might act as a client on some connections and a server on others. We use … … 314 314 message. 315 315 </t> 316 <x:note>317 <t>318 &Note; The term 'user agent' covers both those situations where319 there is a user (human) interacting with the software agent (and for which320 user interface or interactive suggestions might be made, e.g., warning the321 user or given the user an option in the case of security or privacy322 options) and also those where the software agent can act autonomously.323 </t>324 </x:note>325 316 <t> 326 317 Most HTTP communication consists of a retrieval request (GET) for … … 338 329 <iref primary="true" item="response"/> 339 330 <t> 340 A client sends an HTTP request to theserver in the form of a <x:dfn>request</x:dfn>331 A client sends an HTTP request to a server in the form of a <x:dfn>request</x:dfn> 341 332 message, beginning with a request-line that includes a method, URI, and 342 333 protocol version (<xref target="request.line"/>), … … 349 340 </t> 350 341 <t> 351 A server responds to theclient's request by sending one or more HTTP342 A server responds to a client's request by sending one or more HTTP 352 343 <x:dfn>response</x:dfn> 353 344 messages, each beginning with a status line that … … 389 380 <x:span anchor="exbody">Hello World! 390 381 </x:span></artwork></figure> 382 </section> 383 384 <section title="Implementation Diversity" anchor="implementation-diversity"> 385 <t> 386 When considering the design of HTTP, it is easy to fall into a trap of 387 thinking that all user agents are general-purpose browsers and all origin 388 servers are large public websites. That is not the case in practice. 389 Common HTTP user agents include household appliances, stereos, scales, 390 software/firmware updaters, command-line programs, mobile apps, 391 and communication devices in a multitude of shapes and sizes. Likewise, 392 common HTTP origin servers include home automation units, configurable 393 networking components, office machines, autonomous robots, news feeds, 394 traffic cameras, ad selectors, and video delivery platforms. 395 </t> 396 <t> 397 The term "user agent" does not imply that there is a human user directly 398 interacting with the software agent at the time of a request. In many 399 cases, a user agent is installed or configured to run in the background 400 and save its results for later inspection (or save only a subset of those 401 results that might be interesting or erroneous). Spiders, for example, are 402 typically given a start URI and configured to follow certain behavior while 403 crawling the Web as a hypertext graph. 404 </t> 405 <t> 406 The implementation diversity of HTTP means that we cannot assume the 407 user agent can make interactive suggestions to a user or provide adequate 408 warning for security or privacy options. In the few cases where this 409 specification requires reporting of errors to the user, it is acceptable 410 for such reporting to only be visible in an error console or log file. 411 Likewise, requirements that an automated action be confirmed by the user 412 before proceeding can me met via advance configuration choices, 413 run-time options, or simply not proceeding with the unsafe action. 414 </t> 391 415 </section> 392 416 … … 1635 1659 </t> 1636 1660 <t> 1637 HTTP's use of Content-Length is significantly different from how it is1638 used in MIME, where it is an optional field used only within the1639 "message/external-body" media-type.1640 </t>1641 <t>1642 1661 Any Content-Length field value greater than or equal to zero is valid. 1643 1662 Since there is no predefined limit to the length of an HTTP payload, … … 1658 1677 length. 1659 1678 </t> 1679 <x:note> 1680 <t> 1681 &Note; HTTP's use of Content-Length for message framing differs 1682 significantly from the same field's use in MIME, where it is an optional 1683 field used only within the "message/external-body" media-type. 1684 </t> 1685 </x:note> 1660 1686 </section> 1661 1687
Note: See TracChangeset
for help on using the changeset viewer.