| 741 | | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> |
| 742 | | <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and |
| 743 | | MIME-like message payloads for flexible interaction with network-based hypertext information systems. This document is the |
| 744 | | first in a series of documents that collectively form the HTTP/1.1 specification: |
| 745 | | </p> |
| 746 | | <ul class="empty"> |
| 747 | | <li>RFC xxx1: Message Routing and Syntax</li> |
| 748 | | <li><cite title="HTTP/1.1, part 2: Semantics and Payloads" id="rfc.xref.Part2.1">RFC xxx2</cite>: Semantics and Payloads |
| 749 | | </li> |
| 750 | | <li><cite title="HTTP/1.1, part 4: Conditional Requests" id="rfc.xref.Part4.1">RFC xxx3</cite>: Conditional Requests |
| 751 | | </li> |
| 752 | | <li><cite title="HTTP/1.1, part 5: Range Requests" id="rfc.xref.Part5.1">RFC xxx4</cite>: Range Requests |
| 753 | | </li> |
| 754 | | <li><cite title="HTTP/1.1, part 6: Caching" id="rfc.xref.Part6.1">RFC xxx5</cite>: Caching |
| 755 | | </li> |
| 756 | | <li><cite title="HTTP/1.1, part 7: Authentication" id="rfc.xref.Part7.1">RFC xxx6</cite>: Authentication |
| 757 | | </li> |
| 758 | | </ul> |
| 759 | | <p id="rfc.section.1.p.2">This HTTP/1.1 specification obsoletes and moves to historic status <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite>, its predecessor <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.1">RFC 2068</cite>, <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning), and <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">RFC 2817</cite> (on using CONNECT for TLS upgrades). |
| 760 | | </p> |
| 761 | | <p id="rfc.section.1.p.3">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented |
| 762 | | by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do |
| 763 | | not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated |
| 764 | | with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used |
| 765 | | effectively in many different contexts and for which implementations can evolve independently over time. |
| 766 | | </p> |
| 767 | | <p id="rfc.section.1.p.4">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information |
| 768 | | systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols |
| 769 | | into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. |
| 770 | | </p> |
| 771 | | <p id="rfc.section.1.p.5">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, |
| 772 | | we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of |
| 773 | | recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding |
| 774 | | changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps |
| 775 | | at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. |
| 776 | | </p> |
| 777 | | <p id="rfc.section.1.p.6">This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI |
| 778 | | schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. |
| 779 | | Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, |
| 780 | | thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. |
| 781 | | </p> |
| 782 | | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirement Notation</a></h2> |
| 783 | | <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" |
| 784 | | in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. |
| 785 | | </p> |
| 786 | | <div id="rfc.iref.g.1"></div> |
| 787 | | <div id="rfc.iref.g.2"></div> |
| 788 | | <div id="rfc.iref.g.3"></div> |
| 789 | | <div id="rfc.iref.g.4"></div> |
| 790 | | <div id="rfc.iref.g.5"></div> |
| 791 | | <div id="rfc.iref.g.6"></div> |
| 792 | | <div id="rfc.iref.g.7"></div> |
| 793 | | <div id="rfc.iref.g.8"></div> |
| 794 | | <div id="rfc.iref.g.9"></div> |
| 795 | | <div id="rfc.iref.g.10"></div> |
| 796 | | <div id="rfc.iref.g.11"></div> |
| 797 | | <div id="rfc.iref.g.12"></div> |
| 798 | | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> |
| 799 | | <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="#abnf.extension" title="ABNF list extension: #rule">Appendix B</a>. <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF with the list rule expanded. |
| 800 | | </p> |
| 801 | | <div id="core.rules"> |
| 802 | | <p id="rfc.section.1.2.p.2"> The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG |
| 803 | | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
| 804 | | (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character). |
| | 753 | <div id="introduction"> |
| | 754 | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a></h1> |
| | 755 | <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and |
| | 756 | MIME-like message payloads for flexible interaction with network-based hypertext information systems. This document is the |
| | 757 | first in a series of documents that collectively form the HTTP/1.1 specification: |
| 865 | | </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> |
| 866 | | <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 |
| 867 | | and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household |
| 868 | | appliances, stereos, scales, software/firmware updaters, command-line programs, mobile apps, and communication devices in |
| 869 | | a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking |
| 870 | | components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms. |
| 871 | | </p> |
| 872 | | <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 |
| 873 | | a request. In many cases, a user agent is installed or configured to run in the background and save its results for later |
| 874 | | inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically |
| 875 | | given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph. |
| 876 | | </p> |
| 877 | | <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 |
| 878 | | or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting |
| 879 | | of errors to the user, it is acceptable for such reporting to only be visible in an error console or log file. Likewise, requirements |
| 880 | | that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, run-time |
| 881 | | options, or simply not proceeding with the unsafe action. |
| 882 | | </p> |
| 883 | | <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> |
| 884 | | <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 |
| 885 | | transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request |
| 886 | | and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. |
| 887 | | </p> |
| 888 | | <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 |
| 889 | | (<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 |
| 890 | | a proxy via some other connection port or protocol instead of using the defaults. |
| 891 | | </p> |
| 892 | | <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>. |
| 893 | | </p> |
| 894 | | <div id="rfc.iref.i.1"></div> |
| 895 | | <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> |
| 896 | | <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 |
| 897 | | HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, |
| 898 | | switching behavior based on the nature of each request. |
| 899 | | </p> |
| 900 | | <div id="rfc.figure.u.4"></div><pre class="drawing"> > > > > |
| | 886 | </span></pre></div> |
| | 887 | <div id="implementation-diversity"> |
| | 888 | <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a href="#implementation-diversity">Implementation Diversity</a></h2> |
| | 889 | <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 |
| | 890 | and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household |
| | 891 | appliances, stereos, scales, software/firmware updaters, command-line programs, mobile apps, and communication devices in |
| | 892 | a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking |
| | 893 | components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms. |
| | 894 | </p> |
| | 895 | <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 |
| | 896 | a request. In many cases, a user agent is installed or configured to run in the background and save its results for later |
| | 897 | inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically |
| | 898 | given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph. |
| | 899 | </p> |
| | 900 | <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 |
| | 901 | or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting |
| | 902 | of errors to the user, it is acceptable for such reporting to only be visible in an error console or log file. Likewise, requirements |
| | 903 | that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, run-time |
| | 904 | options, or simply not proceeding with the unsafe action. |
| | 905 | </p> |
| | 906 | </div> |
| | 907 | <div id="transport-independence"> |
| | 908 | <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a href="#transport-independence">Connections and Transport Independence</a></h2> |
| | 909 | <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 |
| | 910 | transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request |
| | 911 | and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. |
| | 912 | </p> |
| | 913 | <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 |
| | 914 | (<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 |
| | 915 | a proxy via some other connection port or protocol instead of using the defaults. |
| | 916 | </p> |
| | 917 | <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>. |
| | 918 | </p> |
| | 919 | </div> |
| | 920 | <div id="intermediaries"> |
| | 921 | <div id="rfc.iref.i.1"></div> |
| | 922 | <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a href="#intermediaries">Intermediaries</a></h2> |
| | 923 | <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 |
| | 924 | HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, |
| | 925 | switching behavior based on the nature of each request. |
| | 926 | </p> |
| | 927 | <div id="rfc.figure.u.4"></div><pre class="drawing"> > > > > |
| 904 | | message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply |
| 905 | | only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along |
| 906 | | the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For |
| 907 | | example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, |
| 908 | | at the same time that it is handling A's request. |
| 909 | | </p> |
| 910 | | <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. |
| 911 | | 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. |
| 912 | | </p> |
| 913 | | <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 |
| 914 | | for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations |
| 915 | | are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely |
| 916 | | different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary |
| 917 | | for the sake of security, annotation services, or shared caching. |
| 918 | | </p> |
| 919 | | <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, |
| 920 | | beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original |
| 921 | | sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared |
| 922 | | annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, |
| 923 | | or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) |
| 924 | | that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform |
| 925 | | a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. |
| 926 | | </p> |
| 927 | | <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 |
| 928 | | server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance |
| 929 | | through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. |
| 930 | | </p> |
| 931 | | <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 |
| 932 | | applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound |
| 933 | | servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. |
| 934 | | 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. |
| 935 | | </p> |
| 936 | | <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 |
| 937 | | to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both |
| 938 | | ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as |
| 939 | | when transport-layer security is used to establish private communication through a shared firewall proxy. |
| 940 | | </p> |
| 941 | | <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 |
| 942 | | intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the |
| 943 | | knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems |
| 944 | | by violating HTTP semantics. For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects |
| 945 | | outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public |
| 946 | | network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, |
| 947 | | and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack. |
| 948 | | </p> |
| 949 | | <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 |
| 950 | | depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple |
| 951 | | 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 |
| 952 | | to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems. |
| 953 | | </p> |
| 954 | | <div id="rfc.iref.c.4"></div> |
| 955 | | <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="caches" href="#caches">Caches</a></h2> |
| 956 | | <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. |
| 957 | | A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent |
| 958 | | 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. |
| 959 | | </p> |
| 960 | | <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 |
| 961 | | response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response |
| 962 | | from O (via C) for a request which has not been cached by UA or A. |
| 963 | | </p> |
| 964 | | <div id="rfc.figure.u.5"></div><pre class="drawing"> > > |
| | 931 | message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply |
| | 932 | only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along |
| | 933 | the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For |
| | 934 | example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, |
| | 935 | at the same time that it is handling A's request. |
| | 936 | </p> |
| | 937 | <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. |
| | 938 | 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. |
| | 939 | </p> |
| | 940 | <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 |
| | 941 | for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations |
| | 942 | are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely |
| | 943 | different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary |
| | 944 | for the sake of security, annotation services, or shared caching. |
| | 945 | </p> |
| | 946 | <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, |
| | 947 | beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original |
| | 948 | sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared |
| | 949 | annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, |
| | 950 | or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) |
| | 951 | that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform |
| | 952 | a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. |
| | 953 | </p> |
| | 954 | <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 |
| | 955 | server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance |
| | 956 | through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. |
| | 957 | </p> |
| | 958 | <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 |
| | 959 | applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound |
| | 960 | servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. |
| | 961 | 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. |
| | 962 | </p> |
| | 963 | <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 |
| | 964 | to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both |
| | 965 | ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as |
| | 966 | when transport-layer security is used to establish private communication through a shared firewall proxy. |
| | 967 | </p> |
| | 968 | <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 |
| | 969 | intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the |
| | 970 | knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems |
| | 971 | by violating HTTP semantics. For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects |
| | 972 | outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public |
| | 973 | network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, |
| | 974 | and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack. |
| | 975 | </p> |
| | 976 | <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 |
| | 977 | depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple |
| | 978 | 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 |
| | 979 | to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems. |
| | 980 | </p> |
| | 981 | </div> |
| | 982 | <div id="caches"> |
| | 983 | <div id="rfc.iref.c.4"></div> |
| | 984 | <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a href="#caches">Caches</a></h2> |
| | 985 | <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. |
| | 986 | A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent |
| | 987 | 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. |
| | 988 | </p> |
| | 989 | <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 |
| | 990 | response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response |
| | 991 | from O (via C) for a request which has not been cached by UA or A. |
| | 992 | </p> |
| | 993 | <div id="rfc.figure.u.5"></div><pre class="drawing"> > > |
| 968 | | is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response |
| 969 | | can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| 970 | | </p> |
| 971 | | <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 |
| 972 | | inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems |
| 973 | | that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so |
| 974 | | on. |
| 975 | | </p> |
| 976 | | <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> |
| 977 | | <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 |
| 978 | | requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, |
| 979 | | or caches, depending on what behavior is being constrained by the requirement. |
| 980 | | </p> |
| 981 | | <p id="rfc.section.2.6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely |
| 982 | | forwarding a received element downstream. |
| 983 | | </p> |
| 984 | | <p id="rfc.section.2.6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes |
| 985 | | in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. |
| 986 | | </p> |
| 987 | | <p id="rfc.section.2.6.p.4">In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable |
| 988 | | 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 |
| 989 | | to the recipient's role. |
| 990 | | </p> |
| 991 | | <p id="rfc.section.2.6.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms |
| 992 | | except when they have a direct impact on security, since different applications of the protocol require different error handling |
| 993 | | 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 |
| 994 | | to be dangerous. |
| 995 | | </p> |
| 996 | | <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> |
| 997 | | <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". |
| 998 | | The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's |
| 999 | | corresponding specification of HTTP. |
| 1000 | | </p> |
| 1001 | | <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> |
| 1002 | | <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> |
| | 997 | is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response |
| | 998 | can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| | 999 | </p> |
| | 1000 | <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 |
| | 1001 | inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems |
| | 1002 | that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so |
| | 1003 | on. |
| | 1004 | </p> |
| | 1005 | </div> |
| | 1006 | <div id="intro.conformance.and.error.handling"> |
| | 1007 | <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> |
| | 1008 | <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 |
| | 1009 | requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, |
| | 1010 | or caches, depending on what behavior is being constrained by the requirement. |
| | 1011 | </p> |
| | 1012 | <p id="rfc.section.2.6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely |
| | 1013 | forwarding a received element downstream. |
| | 1014 | </p> |
| | 1015 | <p id="rfc.section.2.6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes |
| | 1016 | in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. |
| | 1017 | </p> |
| | 1018 | <p id="rfc.section.2.6.p.4">In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable |
| | 1019 | 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 |
| | 1020 | to the recipient's role. |
| | 1021 | </p> |
| | 1022 | <p id="rfc.section.2.6.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms |
| | 1023 | except when they have a direct impact on security, since different applications of the protocol require different error handling |
| | 1024 | 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 |
| | 1025 | to be dangerous. |
| | 1026 | </p> |
| | 1027 | </div> |
| | 1028 | <div id="http.version"> |
| | 1029 | <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a href="#http.version">Protocol Versioning</a></h2> |
| | 1030 | <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". |
| | 1031 | The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's |
| | 1032 | corresponding specification of HTTP. |
| | 1033 | </p> |
| | 1034 | <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> |
| | 1035 | <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> |
| 1005 | | version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version |
| 1006 | | to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's |
| 1007 | | communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting |
| 1008 | | the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). |
| 1009 | | </p> |
| 1010 | | <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 |
| 1011 | | message if all of the newer features are ignored. This specification places recipient-version requirements on some new features |
| 1012 | | so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt |
| 1013 | | of a message, that the recipient supports HTTP/1.1. |
| 1014 | | </p> |
| 1015 | | <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 |
| 1016 | | behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 |
| 1017 | | 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. |
| 1018 | | </p> |
| 1019 | | <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 |
| 1020 | | 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 |
| 1021 | | 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. |
| 1022 | | </p> |
| 1023 | | <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 |
| 1024 | | to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without |
| 1025 | | rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version |
| 1026 | | to determine what features are safe to use for later communication with that sender. |
| 1027 | | </p> |
| 1028 | | <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 |
| 1029 | | 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. |
| 1030 | | </p> |
| 1031 | | <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 |
| 1032 | | 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. |
| 1033 | | </p> |
| 1034 | | <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 |
| 1035 | | 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 |
| 1036 | | Supported)</a> response if it cannot send a response using the major version used in the client's request. |
| 1037 | | </p> |
| 1038 | | <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 |
| 1039 | | specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version |
| 1040 | | number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the |
| 1041 | | 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. |
| 1042 | | </p> |
| 1043 | | <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 |
| 1044 | | is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding |
| 1045 | | to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented |
| 1046 | | for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol. |
| 1047 | | </p> |
| 1048 | | <div id="rfc.iref.r.5"></div> |
| 1049 | | <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> |
| 1050 | | <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, |
| 1051 | | and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to |
| 1052 | | 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>. |
| 1053 | | </p> |
| 1054 | | <p id="rfc.section.2.8.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| 1055 | | "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. |
| 1056 | | </p> |
| 1057 | | <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>> |
| 1058 | | <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> |
| 1059 | | <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>> |
| 1060 | | <a href="#uri" class="smpl">authority</a> = <authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>> |
| 1061 | | <a href="#uri" class="smpl">path-abempty</a> = <path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> |
| 1062 | | <a href="#uri" class="smpl">path-absolute</a> = <path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> |
| 1063 | | <a href="#uri" class="smpl">port</a> = <port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>> |
| 1064 | | <a href="#uri" class="smpl">query</a> = <query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>> |
| 1065 | | <a href="#uri" class="smpl">uri-host</a> = <host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.13"><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>> |
| | 1038 | version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version |
| | 1039 | to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's |
| | 1040 | communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting |
| | 1041 | the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). |
| | 1042 | </p> |
| | 1043 | <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 |
| | 1044 | message if all of the newer features are ignored. This specification places recipient-version requirements on some new features |
| | 1045 | so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt |
| | 1046 | of a message, that the recipient supports HTTP/1.1. |
| | 1047 | </p> |
| | 1048 | <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 |
| | 1049 | behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 |
| | 1050 | 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. |
| | 1051 | </p> |
| | 1052 | <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 |
| | 1053 | 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 |
| | 1054 | 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. |
| | 1055 | </p> |
| | 1056 | <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 |
| | 1057 | to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without |
| | 1058 | rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version |
| | 1059 | to determine what features are safe to use for later communication with that sender. |
| | 1060 | </p> |
| | 1061 | <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 |
| | 1062 | 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. |
| | 1063 | </p> |
| | 1064 | <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 |
| | 1065 | 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. |
| | 1066 | </p> |
| | 1067 | <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 |
| | 1068 | 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 |
| | 1069 | Supported)</a> response if it cannot send a response using the major version used in the client's request. |
| | 1070 | </p> |
| | 1071 | <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 |
| | 1072 | specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version |
| | 1073 | number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the |
| | 1074 | given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <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. |
| | 1075 | </p> |
| | 1076 | <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 |
| | 1077 | is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding |
| | 1078 | to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented |
| | 1079 | for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol. |
| | 1080 | </p> |
| | 1081 | </div> |
| | 1082 | <div id="uri"> |
| | 1083 | <div id="rfc.iref.r.5"></div> |
| | 1084 | <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <a href="#uri">Uniform Resource Identifiers</a></h2> |
| | 1085 | <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, |
| | 1086 | and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to |
| | 1087 | 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>. |
| | 1088 | </p> |
| | 1089 | <p id="rfc.section.2.8.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| | 1090 | "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. |
| | 1091 | </p> |
| | 1092 | <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>> |
| | 1093 | <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> |
| | 1094 | <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>> |
| | 1095 | <a href="#uri" class="smpl">authority</a> = <authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>> |
| | 1096 | <a href="#uri" class="smpl">path-abempty</a> = <path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> |
| | 1097 | <a href="#uri" class="smpl">path-absolute</a> = <path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> |
| | 1098 | <a href="#uri" class="smpl">port</a> = <port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>> |
| | 1099 | <a href="#uri" class="smpl">query</a> = <query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>> |
| | 1100 | <a href="#uri" class="smpl">uri-host</a> = <host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>> |
| 1069 | | any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, |
| 1070 | | or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request |
| 1071 | | URI (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>). |
| 1072 | | </p> |
| 1073 | | <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> |
| 1074 | | <div id="rfc.iref.h.1"></div> |
| 1075 | | <div id="rfc.iref.u.3"></div> |
| 1076 | | <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 |
| 1077 | | namespace governed by a potential HTTP origin server listening for TCP connections on a given port. |
| 1078 | | </p> |
| 1079 | | <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] |
| 1080 | | </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 |
| 1081 | | identifier for a potential resource within that origin server's name space. |
| 1082 | | </p> |
| 1083 | | <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 |
| 1084 | | TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient |
| 1085 | | 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 |
| 1086 | | port for WWW services). |
| 1087 | | </p> |
| 1088 | | <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. |
| 1089 | | The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening |
| 1090 | | to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish |
| 1091 | | a naming authority (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that |
| 1092 | | authority to determine which names are valid and how they might be used. |
| 1093 | | </p> |
| 1094 | | <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, |
| 1095 | | and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. |
| 1096 | | </p> |
| 1097 | | <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 |
| 1098 | | delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol |
| 1099 | | would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require |
| 1100 | | an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources |
| 1101 | | — it is only the authoritative interface used for mapping the namespace that is specific to TCP. |
| 1102 | | </p> |
| 1103 | | <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 |
| 1104 | | configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, |
| 1105 | | 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 |
| 1106 | | that contain a URI reference <em class="bcp14">SHOULD</em> parse for the existence of userinfo and treat its presence as an error, likely indicating that the deprecated subcomponent |
| 1107 | | is being used to obscure the authority for the sake of phishing attacks. |
| 1108 | | </p> |
| 1109 | | <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> |
| 1110 | | <div id="rfc.iref.h.2"></div> |
| 1111 | | <div id="rfc.iref.u.4"></div> |
| 1112 | | <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 |
| 1113 | | namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. |
| 1114 | | </p> |
| 1115 | | <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 |
| 1116 | | 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. |
| 1117 | | </p> |
| 1118 | | <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] |
| | 1104 | any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, |
| | 1105 | or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request |
| | 1106 | URI (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>). |
| | 1107 | </p> |
| | 1108 | <div id="http.uri"> |
| | 1109 | <h3 id="rfc.section.2.8.1"><a href="#rfc.section.2.8.1">2.8.1</a> <a href="#http.uri">http URI scheme</a></h3> |
| | 1110 | <div id="rfc.iref.h.1"></div> |
| | 1111 | <div id="rfc.iref.u.3"></div> |
| | 1112 | <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 |
| | 1113 | namespace governed by a potential HTTP origin server listening for TCP connections on a given port. |
| | 1114 | </p> |
| | 1115 | <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] |
| | 1116 | </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="https://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 |
| | 1117 | identifier for a potential resource within that origin server's name space. |
| | 1118 | </p> |
| | 1119 | <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 |
| | 1120 | TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient |
| | 1121 | 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 |
| | 1122 | port for WWW services). |
| | 1123 | </p> |
| | 1124 | <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. |
| | 1125 | The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening |
| | 1126 | to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish |
| | 1127 | a naming authority (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that |
| | 1128 | authority to determine which names are valid and how they might be used. |
| | 1129 | </p> |
| | 1130 | <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, |
| | 1131 | and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. |
| | 1132 | </p> |
| | 1133 | <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 |
| | 1134 | delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol |
| | 1135 | would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require |
| | 1136 | an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources |
| | 1137 | — it is only the authoritative interface used for mapping the namespace that is specific to TCP. |
| | 1138 | </p> |
| | 1139 | <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="https://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 |
| | 1140 | configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, |
| | 1141 | 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 |
| | 1142 | that contain a URI reference <em class="bcp14">SHOULD</em> parse for the existence of userinfo and treat its presence as an error, likely indicating that the deprecated subcomponent |
| | 1143 | is being used to obscure the authority for the sake of phishing attacks. |
| | 1144 | </p> |
| | 1145 | </div> |
| | 1146 | <div id="https.uri"> |
| | 1147 | <h3 id="rfc.section.2.8.2"><a href="#rfc.section.2.8.2">2.8.2</a> <a href="#https.uri">https URI scheme</a></h3> |
| | 1148 | <div id="rfc.iref.h.2"></div> |
| | 1149 | <div id="rfc.iref.u.4"></div> |
| | 1150 | <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 |
| | 1151 | namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. |
| | 1152 | </p> |
| | 1153 | <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 |
| | 1154 | 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. |
| | 1155 | </p> |
| | 1156 | <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] |
| 1240 | | the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. |
| 1241 | | </p> |
| 1242 | | <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining |
| 1243 | | new semantics, or on the number of header fields used in a given message. Existing fields are defined in each part of this |
| 1244 | | specification and in many other specifications outside the standards process. New header fields can be introduced without |
| 1245 | | changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize |
| 1246 | | them. |
| 1247 | | </p> |
| 1248 | | <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. |
| 1249 | | </p> |
| 1250 | | <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" |
| 1251 | | to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include |
| 1252 | | conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. |
| 1253 | | </p> |
| 1254 | | <p id="rfc.section.3.2.p.7">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)]. |
| 1255 | | Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing |
| 1256 | | the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by |
| 1257 | | a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation |
| 1258 | | of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. |
| 1259 | | </p> |
| 1260 | | <div class="note" id="rfc.section.3.2.p.8"> |
| 1261 | | <p> <b>Note:</b> The "Set-Cookie" header field as implemented in practice can occur multiple times, but does not use the list syntax, and thus |
| 1262 | | cannot be combined into a single line (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>). (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem. |
| 1263 | | </p> |
| 1264 | | </div> |
| 1265 | | <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="whitespace" href="#whitespace">Whitespace</a></h3> |
| 1266 | | <div id="rule.LWS"> |
| 1267 | | <p id="rfc.section.3.2.1.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), |
| 1268 | | and BWS ("bad" whitespace). |
| 1269 | | </p> |
| 1270 | | </div> |
| 1271 | | <div id="rule.OWS"> |
| 1272 | | <p id="rfc.section.3.2.1.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting |
| 1273 | | the field value or forwarding the message downstream. |
| 1274 | | </p> |
| 1275 | | </div> |
| 1276 | | <div id="rule.RWS"> |
| 1277 | | <p id="rfc.section.3.2.1.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the |
| 1278 | | message downstream. |
| 1279 | | </p> |
| 1280 | | </div> |
| 1281 | | <div id="rule.BWS"> |
| 1282 | | <p id="rfc.section.3.2.1.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. |
| 1283 | | </p> |
| 1284 | | </div> |
| 1285 | | <div id="rule.whitespace"> |
| 1286 | | <p id="rfc.section.3.2.1.p.5"> </p> |
| 1287 | | </div> |
| 1288 | | <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) |
| | 1291 | the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. |
| | 1292 | </p> |
| | 1293 | <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining |
| | 1294 | new semantics, or on the number of header fields used in a given message. Existing fields are defined in each part of this |
| | 1295 | specification and in many other specifications outside the standards process. New header fields can be introduced without |
| | 1296 | changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize |
| | 1297 | them. |
| | 1298 | </p> |
| | 1299 | <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. |
| | 1300 | </p> |
| | 1301 | <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" |
| | 1302 | to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include |
| | 1303 | conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. |
| | 1304 | </p> |
| | 1305 | <p id="rfc.section.3.2.p.7">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)]. |
| | 1306 | Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing |
| | 1307 | the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by |
| | 1308 | a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation |
| | 1309 | of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. |
| | 1310 | </p> |
| | 1311 | <div class="note" id="rfc.section.3.2.p.8"> |
| | 1312 | <p><b>Note:</b> The "Set-Cookie" header field as implemented in practice can occur multiple times, but does not use the list syntax, and thus |
| | 1313 | cannot be combined into a single line (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>). (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem. |
| | 1314 | </p> |
| | 1315 | </div> |
| | 1316 | <div id="whitespace"> |
| | 1317 | <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#whitespace">Whitespace</a></h3> |
| | 1318 | <div id="rule.LWS"> |
| | 1319 | <p id="rfc.section.3.2.1.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), |
| | 1320 | and BWS ("bad" whitespace). |
| | 1321 | </p> |
| | 1322 | </div> |
| | 1323 | <div id="rule.OWS"> |
| | 1324 | <p id="rfc.section.3.2.1.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting |
| | 1325 | the field value or forwarding the message downstream. |
| | 1326 | </p> |
| | 1327 | </div> |
| | 1328 | <div id="rule.RWS"> |
| | 1329 | <p id="rfc.section.3.2.1.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the |
| | 1330 | message downstream. |
| | 1331 | </p> |
| | 1332 | </div> |
| | 1333 | <div id="rule.BWS"> |
| | 1334 | <p id="rfc.section.3.2.1.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. |
| | 1335 | </p> |
| | 1336 | </div> |
| | 1337 | <div id="rule.whitespace"> |
| | 1338 | <p id="rfc.section.3.2.1.p.5"> </p> |
| | 1339 | </div> |
| | 1340 | <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) |
| 1358 | | <p id="rfc.section.3.2.4.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> |
| | 1416 | <p id="rfc.section.3.2.4.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> |
| | 1417 | </div> |
| | 1418 | <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) |
| | 1419 | </pre><p id="rfc.section.3.2.4.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and |
| | 1420 | ")"). |
| | 1421 | </p> |
| | 1422 | </div> |
| | 1423 | </div> |
| | 1424 | <div id="message.body"> |
| | 1425 | <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a href="#message.body">Message Body</a></h2> |
| | 1426 | <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body |
| | 1427 | is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>. |
| | 1428 | </p> |
| | 1429 | <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET |
| | 1430 | </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p> |
| | 1431 | <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if the method does not define any use for a |
| | 1432 | message body. |
| | 1433 | </p> |
| | 1434 | <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response |
| | 1435 | status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. |
| | 1436 | </p> |
| | 1437 | <div id="header.transfer-encoding"> |
| | 1438 | <div id="rfc.iref.t.4"></div> |
| | 1439 | <div id="rfc.iref.h.6"></div> |
| | 1440 | <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a href="#header.transfer-encoding">Transfer-Encoding</a></h3> |
| | 1441 | <p id="rfc.section.3.3.1.p.1">When one or more transfer codings are applied to a payload body in order to form the message body, a Transfer-Encoding header |
| | 1442 | field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer codings are defined |
| | 1443 | in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. |
| | 1444 | </p> |
| | 1445 | <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> |
| | 1446 | </pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport |
| | 1447 | of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="https://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is |
| | 1448 | primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only |
| | 1449 | applied for transport efficiency or security from those that are characteristics of the target resource. |
| | 1450 | </p> |
| | 1451 | <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size |
| | 1452 | is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message body. If any transfer-coding is applied to a request payload body, the final transfer-coding |
| | 1453 | applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. |
| | 1454 | </p> |
| | 1455 | <div id="rfc.figure.u.27"></div> |
| | 1456 | <p>For example,</p><pre class="text"> Transfer-Encoding: gzip, chunked |
| | 1457 | </pre><p>indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while |
| | 1458 | forming the message body. |
| | 1459 | </p> |
| | 1460 | <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. |
| | 1461 | </p> |
| | 1462 | <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. |
| | 1463 | </p> |
| | 1464 | <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer |
| | 1465 | coding to the message body if the request had been an unconditional GET. This indication is not required, however, because |
| | 1466 | any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. |
| | 1467 | </p> |
| | 1468 | <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will |
| | 1469 | not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge |
| | 1470 | might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). |
| | 1471 | </p> |
| | 1472 | <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> and then close the connection. |
| | 1473 | </p> |
| | 1474 | </div> |
| | 1475 | <div id="header.content-length"> |
| | 1476 | <div id="rfc.iref.c.6"></div> |
| | 1477 | <div id="rfc.iref.h.7"></div> |
| | 1478 | <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a href="#header.content-length">Content-Length</a></h3> |
| | 1479 | <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field and the payload body length can be determined prior to being transferred, a Content-Length header field <em class="bcp14">SHOULD</em> be sent to indicate the length of the payload body that is either present as the message body, for requests and non-HEAD responses |
| | 1480 | other than <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, or would have been present had the request been an unconditional GET. The length is expressed as a decimal number of octets. |
| | 1481 | </p> |
| | 1482 | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> |
| | 1483 | </pre><p id="rfc.section.3.3.2.p.3">An example is</p> |
| | 1484 | <div id="rfc.figure.u.29"></div><pre class="text"> Content-Length: 3495 |
| | 1485 | </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential |
| | 1486 | transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would |
| | 1487 | have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. |
| | 1488 | </p> |
| | 1489 | <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 |
| | 1490 | 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>). |
| | 1491 | </p> |
| | 1492 | <p id="rfc.section.3.3.2.p.7">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, |
| | 1493 | or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length: |
| | 1494 | 42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, |
| | 1495 | 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 |
| | 1496 | that decimal value prior to determining the message body length. |
| | 1497 | </p> |
| | 1498 | <div class="note" id="rfc.section.3.3.2.p.8"> |
| | 1499 | <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 |
| | 1500 | field used only within the "message/external-body" media-type. |
| | 1501 | </p> |
| | 1502 | </div> |
| | 1503 | </div> |
| | 1504 | <div id="message.body.length"> |
| | 1505 | <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a href="#message.body.length">Message Body Length</a></h3> |
| | 1506 | <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> |
| | 1507 | <p id="rfc.section.3.3.3.p.2"></p> |
| | 1508 | <ol> |
| | 1509 | <li> |
| | 1510 | <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present |
| | 1511 | in the message, and thus cannot contain a message body. |
| | 1512 | </p> |
| | 1513 | </li> |
| | 1514 | <li> |
| | 1515 | <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes |
| | 1516 | the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message. |
| | 1517 | </p> |
| | 1518 | </li> |
| | 1519 | <li> |
| | 1520 | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding |
| | 1521 | indicates the data is complete. |
| | 1522 | </p> |
| | 1523 | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the "chunked" transfer-coding is not the final encoding, the message body length |
| | 1524 | is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in |
| | 1525 | a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot be determined reliably; |
| | 1526 | the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. |
| | 1527 | </p> |
| | 1528 | <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request |
| | 1529 | or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an |
| | 1530 | error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message body length after the transfer-coding |
| | 1531 | is decoded. |
| | 1532 | </p> |
| | 1533 | </li> |
| | 1534 | <li> |
| | 1535 | <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message |
| | 1536 | framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent, |
| | 1537 | it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection. |
| | 1538 | </p> |
| | 1539 | </li> |
| | 1540 | <li> |
| | 1541 | <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the message body length in octets. If the actual number of octets sent in the message is less |
| | 1542 | than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in |
| | 1543 | the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection |
| | 1544 | and the connection has been closed by the server. |
| | 1545 | </p> |
| | 1546 | </li> |
| | 1547 | <li> |
| | 1548 | <p>If this is a request message and none of the above are true, then the message body length is zero (no message body is present).</p> |
| | 1549 | </li> |
| | 1550 | <li> |
| | 1551 | <p>Otherwise, this is a response message without a declared message body length, so the message body length is determined by |
| | 1552 | the number of octets received prior to the server closing the connection. |
| | 1553 | </p> |
| | 1554 | </li> |
| | 1555 | </ol> |
| | 1556 | <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted |
| | 1557 | by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility |
| | 1558 | with HTTP/1.0. |
| | 1559 | </p> |
| | 1560 | <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>. |
| | 1561 | </p> |
| | 1562 | <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the "chunked" encoding, since some existing services |
| | 1563 | respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via |
| | 1564 | a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire |
| | 1565 | request before processing. |
| | 1566 | </p> |
| | 1567 | <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of |
| | 1568 | specific user configuration or by remembering the version of a prior received response. |
| | 1569 | </p> |
| | 1570 | </div> |
| | 1571 | </div> |
| | 1572 | <div id="incomplete.messages"> |
| | 1573 | <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a href="#incomplete.messages">Handling Incomplete Messages</a></h2> |
| | 1574 | <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a canceled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. |
| | 1575 | </p> |
| | 1576 | <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number |
| | 1577 | of octets or by failure to decode a transfer-encoded message body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received) |
| | 1578 | cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error. |
| | 1579 | </p> |
| | 1580 | <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding |
| | 1581 | has not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response |
| | 1582 | that has neither chunked transfer encoding nor Content-Length is terminated by closure of the connection, and thus is considered |
| | 1583 | complete regardless of the number of message body octets received, provided that the header block was received intact. |
| | 1584 | </p> |
| | 1585 | <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that |
| | 1586 | an error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| | 1587 | </p> |
| | 1588 | <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data |
| | 1589 | on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple |
| | 1590 | requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.3.2.2</a>. |
| | 1591 | </p> |
| | 1592 | </div> |
| | 1593 | <div id="message.robustness"> |
| | 1594 | <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a href="#message.robustness">Message Parsing Robustness</a></h2> |
| | 1595 | <p id="rfc.section.3.5.p.1">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server |
| | 1596 | applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then |
| | 1597 | the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length. |
| | 1598 | </p> |
| | 1599 | <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if the server is reading the protocol |
| | 1600 | stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend |
| | 1601 | that recipients recognize a single LF as a line terminator and ignore any CR. |
| | 1602 | </p> |
| | 1603 | <p id="rfc.section.3.5.p.3">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request |
| | 1604 | message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed |
| | 1605 | above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response. |
| | 1606 | </p> |
| | 1607 | </div> |
| 1360 | | <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) |
| 1361 | | </pre><p id="rfc.section.3.2.4.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and |
| 1362 | | ")"). |
| 1363 | | </p> |
| 1364 | | <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> |
| 1365 | | <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body |
| 1366 | | is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>. |
| 1367 | | </p> |
| 1368 | | <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET |
| 1369 | | </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p> |
| 1370 | | <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if the method does not define any use for a |
| 1371 | | message body. |
| 1372 | | </p> |
| 1373 | | <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response |
| 1374 | | status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. |
| 1375 | | </p> |
| 1376 | | <div id="rfc.iref.t.4"></div> |
| 1377 | | <div id="rfc.iref.h.6"></div> |
| 1378 | | <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3> |
| 1379 | | <p id="rfc.section.3.3.1.p.1">When one or more transfer codings are applied to a payload body in order to form the message body, a Transfer-Encoding header |
| 1380 | | field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer codings are defined |
| 1381 | | in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. |
| 1382 | | </p> |
| 1383 | | <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> |
| 1384 | | </pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport |
| 1385 | | of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is |
| 1386 | | primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only |
| 1387 | | applied for transport efficiency or security from those that are characteristics of the target resource. |
| 1388 | | </p> |
| 1389 | | <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size |
| 1390 | | is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message body. If any transfer-coding is applied to a request payload body, the final transfer-coding |
| 1391 | | applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. |
| 1392 | | </p> |
| 1393 | | <div id="rfc.figure.u.27"></div> |
| 1394 | | <p>For example,</p><pre class="text"> Transfer-Encoding: gzip, chunked |
| 1395 | | </pre><p>indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while |
| 1396 | | forming the message body. |
| 1397 | | </p> |
| 1398 | | <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. |
| 1399 | | </p> |
| 1400 | | <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. |
| 1401 | | </p> |
| 1402 | | <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer |
| 1403 | | coding to the message body if the request had been an unconditional GET. This indication is not required, however, because |
| 1404 | | any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. |
| 1405 | | </p> |
| 1406 | | <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will |
| 1407 | | not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge |
| 1408 | | might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). |
| 1409 | | </p> |
| 1410 | | <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> and then close the connection. |
| 1411 | | </p> |
| 1412 | | <div id="rfc.iref.c.6"></div> |
| 1413 | | <div id="rfc.iref.h.7"></div> |
| 1414 | | <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h3> |
| 1415 | | <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field and the payload body length can be determined prior to being transferred, a Content-Length header field <em class="bcp14">SHOULD</em> be sent to indicate the length of the payload body that is either present as the message body, for requests and non-HEAD responses |
| 1416 | | other than <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, or would have been present had the request been an unconditional GET. The length is expressed as a decimal number of octets. |
| 1417 | | </p> |
| 1418 | | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> |
| 1419 | | </pre><p id="rfc.section.3.3.2.p.3">An example is</p> |
| 1420 | | <div id="rfc.figure.u.29"></div><pre class="text"> Content-Length: 3495 |
| 1421 | | </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential |
| 1422 | | transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would |
| 1423 | | have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. |
| 1424 | | </p> |
| 1425 | | <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 |
| 1426 | | 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>). |
| 1427 | | </p> |
| 1428 | | <p id="rfc.section.3.3.2.p.7">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, |
| 1429 | | or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length: |
| 1430 | | 42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, |
| 1431 | | 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 |
| 1432 | | that decimal value prior to determining the message body length. |
| 1433 | | </p> |
| 1434 | | <div class="note" id="rfc.section.3.3.2.p.8"> |
| 1435 | | <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 |
| 1436 | | field used only within the "message/external-body" media-type. |
| 1437 | | </p> |
| 1438 | | </div> |
| 1439 | | <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> |
| 1440 | | <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> |
| 1441 | | <p id="rfc.section.3.3.3.p.2"> </p> |
| 1442 | | <ol> |
| 1443 | | <li> |
| 1444 | | <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present |
| 1445 | | in the message, and thus cannot contain a message body. |
| 1446 | | </p> |
| 1447 | | </li> |
| 1448 | | <li> |
| 1449 | | <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes |
| 1450 | | the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message. |
| 1451 | | </p> |
| 1452 | | </li> |
| 1453 | | <li> |
| 1454 | | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding |
| 1455 | | indicates the data is complete. |
| 1456 | | </p> |
| 1457 | | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the "chunked" transfer-coding is not the final encoding, the message body length |
| 1458 | | is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in |
| 1459 | | a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot be determined reliably; |
| 1460 | | the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. |
| 1461 | | </p> |
| 1462 | | <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request |
| 1463 | | or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an |
| 1464 | | error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message body length after the transfer-coding |
| 1465 | | is decoded. |
| 1466 | | </p> |
| 1467 | | </li> |
| 1468 | | <li> |
| 1469 | | <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message |
| 1470 | | framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent, |
| 1471 | | it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection. |
| 1472 | | </p> |
| 1473 | | </li> |
| 1474 | | <li> |
| 1475 | | <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the message body length in octets. If the actual number of octets sent in the message is less |
| 1476 | | than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in |
| 1477 | | the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection |
| 1478 | | and the connection has been closed by the server. |
| 1479 | | </p> |
| 1480 | | </li> |
| 1481 | | <li> |
| 1482 | | <p>If this is a request message and none of the above are true, then the message body length is zero (no message body is present).</p> |
| 1483 | | </li> |
| 1484 | | <li> |
| 1485 | | <p>Otherwise, this is a response message without a declared message body length, so the message body length is determined by |
| 1486 | | the number of octets received prior to the server closing the connection. |
| 1487 | | </p> |
| 1488 | | </li> |
| 1489 | | </ol> |
| 1490 | | <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted |
| 1491 | | by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility |
| 1492 | | with HTTP/1.0. |
| 1493 | | </p> |
| 1494 | | <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>. |
| 1495 | | </p> |
| 1496 | | <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the "chunked" encoding, since some existing services |
| 1497 | | respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via |
| 1498 | | a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire |
| 1499 | | request before processing. |
| 1500 | | </p> |
| 1501 | | <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of |
| 1502 | | specific user configuration or by remembering the version of a prior received response. |
| 1503 | | </p> |
| 1504 | | <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2> |
| 1505 | | <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a canceled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. |
| 1506 | | </p> |
| 1507 | | <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number |
| 1508 | | of octets or by failure to decode a transfer-encoded message body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received) |
| 1509 | | cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error. |
| 1510 | | </p> |
| 1511 | | <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding |
| 1512 | | has not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response |
| 1513 | | that has neither chunked transfer encoding nor Content-Length is terminated by closure of the connection, and thus is considered |
| 1514 | | complete regardless of the number of message body octets received, provided that the header block was received intact. |
| 1515 | | </p> |
| 1516 | | <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that |
| 1517 | | an error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| 1518 | | </p> |
| 1519 | | <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data |
| 1520 | | on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple |
| 1521 | | requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.3.2.2</a>. |
| 1522 | | </p> |
| 1523 | | <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> |
| 1524 | | <p id="rfc.section.3.5.p.1">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server |
| 1525 | | applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then |
| 1526 | | the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length. |
| 1527 | | </p> |
| 1528 | | <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if the server is reading the protocol |
| 1529 | | stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend |
| 1530 | | that recipients recognize a single LF as a line terminator and ignore any CR. |
| 1531 | | </p> |
| 1532 | | <p id="rfc.section.3.5.p.3">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request |
| 1533 | | message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed |
| 1534 | | above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response. |
| 1535 | | </p> |
| 1536 | | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1> |
| 1537 | | <p id="rfc.section.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied |
| 1538 | | to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the |
| 1539 | | transfer-coding is a property of the message rather than a property of the representation that is being transferred. |
| 1540 | | </p> |
| 1541 | | <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> |
| | 1609 | <div id="transfer.codings"> |
| | 1610 | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#transfer.codings">Transfer Codings</a></h1> |
| | 1611 | <p id="rfc.section.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied |
| | 1612 | to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the |
| | 1613 | transfer-coding is a property of the message rather than a property of the representation that is being transferred. |
| | 1614 | </p> |
| | 1615 | <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> |
| 1711 | | <div id="rfc.iref.t.6"></div> |
| 1712 | | <div id="rfc.iref.h.9"></div> |
| 1713 | | <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> |
| 1714 | | <p id="rfc.section.4.4.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with |
| 1715 | | chunked transfer-coding. |
| 1716 | | </p> |
| 1717 | | <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.79"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> |
| 1718 | | </pre><p id="rfc.section.4.4.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient |
| 1719 | | to know which header fields to expect in the trailer. |
| 1720 | | </p> |
| 1721 | | <p id="rfc.section.4.4.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding. |
| 1722 | | </p> |
| 1723 | | <p id="rfc.section.4.4.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields: |
| 1724 | | </p> |
| 1725 | | <ul> |
| 1726 | | <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li> |
| 1727 | | <li><a href="#header.content-length" class="smpl">Content-Length</a></li> |
| 1728 | | <li><a href="#header.trailer" class="smpl">Trailer</a></li> |
| 1729 | | </ul> |
| 1730 | | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> |
| 1731 | | <p id="rfc.section.5.p.1">HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, |
| 1732 | | and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain |
| 1733 | | back to the client. |
| 1734 | | </p> |
| 1735 | | <div id="rfc.iref.t.7"></div> |
| 1736 | | <div id="rfc.iref.t.8"></div> |
| 1737 | | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="target-resource" href="#target-resource">Identifying a Target Resource</a></h2> |
| 1738 | | <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, |
| 1739 | | communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification |
| 1740 | | mechanism and configuration techniques as general-purpose Web browsers. |
| 1741 | | </p> |
| 1742 | | <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 |
| 1743 | | are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.8</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order |
| 1744 | | to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment |
| 1745 | | 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>). |
| 1746 | | </p> |
| 1747 | | <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p> |
| 1748 | | <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="connecting.inbound" href="#connecting.inbound">Connecting Inbound</a></h2> |
| 1749 | | <p id="rfc.section.5.2.p.1">Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired |
| 1750 | | semantics and, if so, where that request is to be directed. |
| 1751 | | </p> |
| 1752 | | <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), then the request is usually directed to the cache first. |
| 1753 | | </p> |
| 1754 | | <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy |
| 1755 | | is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, |
| 1756 | | selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy |
| 1757 | | is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. |
| 1758 | | </p> |
| 1759 | | <p id="rfc.section.5.2.p.4">If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to |
| 1760 | | connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and |
| 1761 | | defined by its associated specification, similar to how this specification defines origin server access for resolution of |
| 1762 | | 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. |
| 1763 | | </p> |
| 1764 | | <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> |
| 1765 | | <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained (<a href="#connection.management" title="Connection Management">Section 6</a>), the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on |
| 1766 | | both the method being requested and whether the request is to a proxy. |
| 1767 | | </p> |
| 1768 | | <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a> |
| | 1821 | <div id="message.routing"> |
| | 1822 | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#message.routing">Message Routing</a></h1> |
| | 1823 | <p id="rfc.section.5.p.1">HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, |
| | 1824 | and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain |
| | 1825 | back to the client. |
| | 1826 | </p> |
| | 1827 | <div id="target-resource"> |
| | 1828 | <div id="rfc.iref.t.7"></div> |
| | 1829 | <div id="rfc.iref.t.8"></div> |
| | 1830 | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a href="#target-resource">Identifying a Target Resource</a></h2> |
| | 1831 | <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, |
| | 1832 | communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification |
| | 1833 | mechanism and configuration techniques as general-purpose Web browsers. |
| | 1834 | </p> |
| | 1835 | <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 |
| | 1836 | are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.8</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order |
| | 1837 | to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment |
| | 1838 | 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="https://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). |
| | 1839 | </p> |
| | 1840 | <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p> |
| | 1841 | </div> |
| | 1842 | <div id="connecting.inbound"> |
| | 1843 | <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a href="#connecting.inbound">Connecting Inbound</a></h2> |
| | 1844 | <p id="rfc.section.5.2.p.1">Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired |
| | 1845 | semantics and, if so, where that request is to be directed. |
| | 1846 | </p> |
| | 1847 | <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), then the request is usually directed to the cache first. |
| | 1848 | </p> |
| | 1849 | <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy |
| | 1850 | is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, |
| | 1851 | selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy |
| | 1852 | is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. |
| | 1853 | </p> |
| | 1854 | <p id="rfc.section.5.2.p.4">If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to |
| | 1855 | connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and |
| | 1856 | defined by its associated specification, similar to how this specification defines origin server access for resolution of |
| | 1857 | 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. |
| | 1858 | </p> |
| | 1859 | </div> |
| | 1860 | <div id="request-target"> |
| | 1861 | <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a href="#request-target">Request Target</a></h2> |
| | 1862 | <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained (<a href="#connection.management" title="Connection Management">Section 6</a>), the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on |
| | 1863 | both the method being requested and whether the request is to a proxy. |
| | 1864 | </p> |
| | 1865 | <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a> |
| 1836 | | to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. |
| 1837 | | </p> |
| 1838 | | <p id="rfc.section.5.4.p.7">When an HTTP/1.1 proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. If |
| 1839 | | the proxy forwards the request, it <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value. |
| 1840 | | </p> |
| 1841 | | <p id="rfc.section.5.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to |
| 1842 | | poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it |
| 1843 | | relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache, |
| 1844 | | without first verifying that the intercepted connection is targeting a valid IP address for that host. |
| 1845 | | </p> |
| 1846 | | <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than |
| 1847 | | one Host header field or a Host header field with an invalid field-value. |
| 1848 | | </p> |
| 1849 | | <div id="rfc.iref.e.1"></div> |
| 1850 | | <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> |
| 1851 | | <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request. |
| 1852 | | The URI derived from this reconstruction process is referred to as the "effective request URI". |
| 1853 | | </p> |
| 1854 | | <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p> |
| 1855 | | <p id="rfc.section.5.5.p.3">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the |
| 1856 | | effective request URI is constructed as follows. |
| 1857 | | </p> |
| 1858 | | <p id="rfc.section.5.5.p.4">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise, |
| 1859 | | the scheme is "http". |
| 1860 | | </p> |
| 1861 | | <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target. |
| 1862 | | Otherwise, if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, then the authority component is the same as the Host field-value. Otherwise, |
| 1863 | | the authority component is the concatenation of the default host name configured for the server, a colon (":"), and the connection's |
| 1864 | | incoming TCP port number in decimal form. |
| 1865 | | </p> |
| 1866 | | <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component |
| 1867 | | is empty. Otherwise, the combined path and query component is the same as the request-target. |
| 1868 | | </p> |
| 1869 | | <p id="rfc.section.5.5.p.7">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating |
| 1870 | | the scheme, "://", authority, and combined path and query component. |
| 1871 | | </p> |
| 1872 | | <div id="rfc.figure.u.48"></div> |
| 1873 | | <p>Example 1: the following message received over an insecure TCP connection</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 |
| | 1935 | to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. |
| | 1936 | </p> |
| | 1937 | <p id="rfc.section.5.4.p.7">When an HTTP/1.1 proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. If |
| | 1938 | the proxy forwards the request, it <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value. |
| | 1939 | </p> |
| | 1940 | <p id="rfc.section.5.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to |
| | 1941 | poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it |
| | 1942 | relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache, |
| | 1943 | without first verifying that the intercepted connection is targeting a valid IP address for that host. |
| | 1944 | </p> |
| | 1945 | <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than |
| | 1946 | one Host header field or a Host header field with an invalid field-value. |
| | 1947 | </p> |
| | 1948 | </div> |
| | 1949 | <div id="effective.request.uri"> |
| | 1950 | <div id="rfc.iref.e.1"></div> |
| | 1951 | <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a href="#effective.request.uri">Effective Request URI</a></h2> |
| | 1952 | <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request. |
| | 1953 | The URI derived from this reconstruction process is referred to as the "effective request URI". |
| | 1954 | </p> |
| | 1955 | <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p> |
| | 1956 | <p id="rfc.section.5.5.p.3">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the |
| | 1957 | effective request URI is constructed as follows. |
| | 1958 | </p> |
| | 1959 | <p id="rfc.section.5.5.p.4">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise, |
| | 1960 | the scheme is "http". |
| | 1961 | </p> |
| | 1962 | <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target. |
| | 1963 | Otherwise, if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, then the authority component is the same as the Host field-value. Otherwise, |
| | 1964 | the authority component is the concatenation of the default host name configured for the server, a colon (":"), and the connection's |
| | 1965 | incoming TCP port number in decimal form. |
| | 1966 | </p> |
| | 1967 | <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component |
| | 1968 | is empty. Otherwise, the combined path and query component is the same as the request-target. |
| | 1969 | </p> |
| | 1970 | <p id="rfc.section.5.5.p.7">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating |
| | 1971 | the scheme, "://", authority, and combined path and query component. |
| | 1972 | </p> |
| | 1973 | <div id="rfc.figure.u.48"></div> |
| | 1974 | <p>Example 1: the following message received over an insecure TCP connection</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 |
| 1880 | | </pre> <div id="rfc.figure.u.51"></div> |
| 1881 | | <p>has an effective request URI of</p> <pre class="text">https://www.example.org |
| 1882 | | </pre> <p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the <a href="#header.host" class="smpl">Host</a> field-value and instead replace it with a configured server name when constructing the effective request URI. |
| 1883 | | </p> |
| 1884 | | <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess |
| 1885 | | the effective request URI's authority component. |
| 1886 | | </p> |
| 1887 | | <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> |
| 1888 | | <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 |
| 1889 | | to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has |
| 1890 | | characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can |
| 1891 | | enhance (or interfere) with either direction of the stream. |
| 1892 | | </p> |
| 1893 | | <p id="rfc.section.5.6.p.2">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses. |
| 1894 | | </p> |
| 1895 | | <p id="rfc.section.5.6.p.3">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. |
| 1896 | | </p> |
| 1897 | | <p id="rfc.section.5.6.p.4">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, |
| 1898 | | except as noted above to replace an empty path with "/" or "*". |
| 1899 | | </p> |
| 1900 | | <p id="rfc.section.5.6.p.5">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 6.1</a>. |
| 1901 | | </p> |
| 1902 | | <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a> <a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h3> |
| 1903 | | <p id="rfc.section.5.6.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p> |
| 1904 | | <ul> |
| 1905 | | <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields |
| 1906 | | in responses <em class="bcp14">MUST</em> be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry. |
| 1907 | | </li> |
| 1908 | | <li>Hop-by-hop header fields, which are meaningful only for a single transport-level connection, and are not stored by caches |
| 1909 | | or forwarded by proxies. |
| 1910 | | </li> |
| 1911 | | </ul> |
| 1912 | | <p id="rfc.section.5.6.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p> |
| 1913 | | <ul> |
| 1914 | | <li><a href="#header.connection" class="smpl">Connection</a></li> |
| 1915 | | <li>Keep-Alive (<a href="http://tools.ietf.org/html/rfc2068#section-19.7.1.1">Section 19.7.1.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>) |
| 1916 | | </li> |
| 1917 | | <li><a href="p7-auth.html#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> (<a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) |
| 1918 | | </li> |
| 1919 | | <li><a href="p7-auth.html#header.proxy-authorization" class="smpl">Proxy-Authorization</a> (<a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) |
| 1920 | | </li> |
| 1921 | | <li><a href="#header.te" class="smpl">TE</a></li> |
| 1922 | | <li><a href="#header.trailer" class="smpl">Trailer</a></li> |
| 1923 | | <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li> |
| 1924 | | <li><a href="#header.upgrade" class="smpl">Upgrade</a></li> |
| 1925 | | </ul> |
| 1926 | | <p id="rfc.section.5.6.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> |
| 1927 | | <p id="rfc.section.5.6.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>). |
| 1928 | | </p> |
| 1929 | | <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h3> |
| 1930 | | <p id="rfc.section.5.6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A non-transforming |
| 1931 | | proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header field unless the definition of that header field requires or specifically allows that. |
| 1932 | | </p> |
| 1933 | | <p id="rfc.section.5.6.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: |
| 1934 | | </p> |
| 1935 | | <ul> |
| 1936 | | <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 9.5</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| 1937 | | </li> |
| 1938 | | <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 9.8</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| 1939 | | </li> |
| 1940 | | <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) |
| 1941 | | </li> |
| 1942 | | <li><a href="p4-conditional.html#header.etag" class="smpl">ETag</a> (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) |
| 1943 | | </li> |
| 1944 | | <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) |
| 1945 | | </li> |
| 1946 | | <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 9.17</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| 1947 | | </li> |
| 1948 | | </ul> |
| 1949 | | <p id="rfc.section.5.6.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response: |
| 1950 | | </p> |
| 1951 | | <ul> |
| 1952 | | <li><a href="p6-cache.html#header.expires" class="smpl">Expires</a> (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) |
| 1953 | | </li> |
| 1954 | | </ul> |
| 1955 | | <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in that response. |
| 1956 | | </p> |
| 1957 | | <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: |
| 1958 | | </p> |
| 1959 | | <ul> |
| 1960 | | <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| 1961 | | </li> |
| 1962 | | <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>) |
| 1963 | | </li> |
| 1964 | | <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| 1965 | | </li> |
| 1966 | | </ul> |
| 1967 | | <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| 1968 | | </p> |
| 1969 | | <div class="note" id="rfc.section.5.6.2.p.7"> |
| 1970 | | <p> <b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms |
| 1971 | | are introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. |
| 1972 | | </p> |
| | 1981 | </pre><div id="rfc.figure.u.51"></div> |
| | 1982 | <p>has an effective request URI of</p><pre class="text">https://www.example.org |
| | 1983 | </pre><p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the <a href="#header.host" class="smpl">Host</a> field-value and instead replace it with a configured server name when constructing the effective request URI. |
| | 1984 | </p> |
| | 1985 | <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess |
| | 1986 | the effective request URI's authority component. |
| | 1987 | </p> |
| | 1988 | </div> |
| | 1989 | <div id="intermediary.forwarding"> |
| | 1990 | <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a href="#intermediary.forwarding">Intermediary Forwarding</a></h2> |
| | 1991 | <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 |
| | 1992 | to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has |
| | 1993 | characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can |
| | 1994 | enhance (or interfere) with either direction of the stream. |
| | 1995 | </p> |
| | 1996 | <p id="rfc.section.5.6.p.2">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses. |
| | 1997 | </p> |
| | 1998 | <p id="rfc.section.5.6.p.3">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. |
| | 1999 | </p> |
| | 2000 | <p id="rfc.section.5.6.p.4">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, |
| | 2001 | except as noted above to replace an empty path with "/" or "*". |
| | 2002 | </p> |
| | 2003 | <p id="rfc.section.5.6.p.5">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 6.1</a>. |
| | 2004 | </p> |
| | 2005 | <div id="end-to-end.and.hop-by-hop.header-fields"> |
| | 2006 | <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a> <a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h3> |
| | 2007 | <p id="rfc.section.5.6.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p> |
| | 2008 | <ul> |
| | 2009 | <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields |
| | 2010 | in responses <em class="bcp14">MUST</em> be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry. |
| | 2011 | </li> |
| | 2012 | <li>Hop-by-hop header fields, which are meaningful only for a single transport-level connection, and are not stored by caches |
| | 2013 | or forwarded by proxies. |
| | 2014 | </li> |
| | 2015 | </ul> |
| | 2016 | <p id="rfc.section.5.6.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p> |
| | 2017 | <ul> |
| | 2018 | <li><a href="#header.connection" class="smpl">Connection</a></li> |
| | 2019 | <li>Keep-Alive (<a href="https://tools.ietf.org/html/rfc2068#section-19.7.1.1">Section 19.7.1.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>) |
| | 2020 | </li> |
| | 2021 | <li><a href="p7-auth.html#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> (<a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) |
| | 2022 | </li> |
| | 2023 | <li><a href="p7-auth.html#header.proxy-authorization" class="smpl">Proxy-Authorization</a> (<a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) |
| | 2024 | </li> |
| | 2025 | <li><a href="#header.te" class="smpl">TE</a></li> |
| | 2026 | <li><a href="#header.trailer" class="smpl">Trailer</a></li> |
| | 2027 | <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li> |
| | 2028 | <li><a href="#header.upgrade" class="smpl">Upgrade</a></li> |
| | 2029 | </ul> |
| | 2030 | <p id="rfc.section.5.6.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> |
| | 2031 | <p id="rfc.section.5.6.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>). |
| | 2032 | </p> |
| | 2033 | </div> |
| | 2034 | <div id="non-modifiable.header-fields"> |
| | 2035 | <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a> <a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h3> |
| | 2036 | <p id="rfc.section.5.6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A non-transforming |
| | 2037 | proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header field unless the definition of that header field requires or specifically allows that. |
| | 2038 | </p> |
| | 2039 | <p id="rfc.section.5.6.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: |
| | 2040 | </p> |
| | 2041 | <ul> |
| | 2042 | <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 9.5</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| | 2043 | </li> |
| | 2044 | <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 9.8</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| | 2045 | </li> |
| | 2046 | <li>Content-MD5 (<a href="https://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) |
| | 2047 | </li> |
| | 2048 | <li><a href="p4-conditional.html#header.etag" class="smpl">ETag</a> (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) |
| | 2049 | </li> |
| | 2050 | <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) |
| | 2051 | </li> |
| | 2052 | <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 9.17</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| | 2053 | </li> |
| | 2054 | </ul> |
| | 2055 | <p id="rfc.section.5.6.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response: |
| | 2056 | </p> |
| | 2057 | <ul> |
| | 2058 | <li><a href="p6-cache.html#header.expires" class="smpl">Expires</a> (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) |
| | 2059 | </li> |
| | 2060 | </ul> |
| | 2061 | <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in that response. |
| | 2062 | </p> |
| | 2063 | <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: |
| | 2064 | </p> |
| | 2065 | <ul> |
| | 2066 | <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| | 2067 | </li> |
| | 2068 | <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>) |
| | 2069 | </li> |
| | 2070 | <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) |
| | 2071 | </li> |
| | 2072 | </ul> |
| | 2073 | <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| | 2074 | </p> |
| | 2075 | <div class="note" id="rfc.section.5.6.2.p.7"> |
| | 2076 | <p><b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms |
| | 2077 | are introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. |
| | 2078 | </p> |
| | 2079 | </div> |
| | 2080 | <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). |
| | 2081 | </p> |
| | 2082 | </div> |
| | 2083 | </div> |
| | 2084 | <div id="associating.response.to.request"> |
| | 2085 | <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a href="#associating.response.to.request">Associating a Response to a Request</a></h2> |
| | 2086 | <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response |
| | 2087 | messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made |
| | 2088 | on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request. |
| | 2089 | </p> |
| | 2090 | <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. |
| | 2091 | </p> |
| | 2092 | </div> |
| 2067 | | by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. |
| 2068 | | </p> |
| 2069 | | <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> |
| 2070 | | <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> |
| 2071 | | <p id="rfc.section.6.3.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers |
| 2072 | | and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make |
| 2073 | | multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a |
| 2074 | | prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. |
| 2075 | | </p> |
| 2076 | | <p id="rfc.section.6.3.1.p.2">Persistent HTTP connections have a number of advantages: </p> |
| 2077 | | <ul> |
| 2078 | | <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, |
| 2079 | | tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts. |
| 2080 | | </li> |
| 2081 | | <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without |
| 2082 | | waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. |
| 2083 | | </li> |
| 2084 | | <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to |
| 2085 | | determine the congestion state of the network. |
| 2086 | | </li> |
| 2087 | | <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li> |
| 2088 | | <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using |
| 2089 | | future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old |
| 2090 | | semantics after an error is reported. |
| 2091 | | </li> |
| 2092 | | </ul> |
| 2093 | | <p id="rfc.section.6.3.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. |
| 2094 | | </p> |
| 2095 | | <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3> |
| 2096 | | <p id="rfc.section.6.3.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior |
| 2097 | | of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server. |
| 2098 | | </p> |
| 2099 | | <p id="rfc.section.6.3.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling |
| 2100 | | takes place using the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. |
| 2101 | | </p> |
| 2102 | | <h4 id="rfc.section.6.3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> |
| 2103 | | <p id="rfc.section.6.3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection |
| 2104 | | immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". |
| 2105 | | </p> |
| 2106 | | <p id="rfc.section.6.3.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains |
| 2107 | | a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that |
| 2108 | | request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". |
| 2109 | | </p> |
| 2110 | | <p id="rfc.section.6.3.2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection. |
| 2111 | | </p> |
| 2112 | | <p id="rfc.section.6.3.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. |
| 2113 | | </p> |
| 2114 | | <p id="rfc.section.6.3.2.1.p.5">Each persistent connection applies to only one transport link.</p> |
| 2115 | | <p id="rfc.section.6.3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). |
| 2116 | | </p> |
| 2117 | | <p id="rfc.section.6.3.2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. |
| 2118 | | </p> |
| 2119 | | <h4 id="rfc.section.6.3.2.2"><a href="#rfc.section.6.3.2.2">6.3.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> |
| 2120 | | <p id="rfc.section.6.3.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received. |
| 2121 | | </p> |
| 2122 | | <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. |
| 2123 | | </p> |
| 2124 | | <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to |
| 2125 | | send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. |
| 2126 | | </p> |
| 2127 | | <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> |
| 2128 | | <p id="rfc.section.6.3.3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers |
| 2129 | | might make this a higher value since it is likely that the client will be making more connections through the same server. |
| 2130 | | The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client |
| 2131 | | or the server. |
| 2132 | | </p> |
| 2133 | | <p id="rfc.section.6.3.3.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does |
| 2134 | | not detect the other side's close promptly it could cause unnecessary resource drain on the network. |
| 2135 | | </p> |
| 2136 | | <p id="rfc.section.6.3.3.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time |
| 2137 | | that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed |
| 2138 | | while it was idle, but from the client's point of view, a request is in progress. |
| 2139 | | </p> |
| 2140 | | <p id="rfc.section.6.3.3.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies). |
| 2141 | | </p> |
| 2142 | | <p id="rfc.section.6.3.3.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many |
| 2143 | | applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages |
| 2144 | | clients to be conservative when opening multiple connections. |
| 2145 | | </p> |
| 2146 | | <p id="rfc.section.6.3.3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant |
| 2147 | | server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used |
| 2148 | | consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side |
| 2149 | | effects in congested networks. |
| 2150 | | </p> |
| 2151 | | <p id="rfc.section.6.3.3.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> |
| 2152 | | <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> |
| 2153 | | <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request |
| 2154 | | sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding |
| 2155 | | of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. |
| 2156 | | </p> |
| 2157 | | <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2> |
| 2158 | | <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3> |
| 2159 | | <p id="rfc.section.6.4.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating |
| 2160 | | connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. |
| 2161 | | </p> |
| 2162 | | <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> |
| 2163 | | <p id="rfc.section.6.4.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error |
| 2164 | | status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection. |
| 2165 | | </p> |
| 2166 | | <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> |
| 2167 | | <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing |
| 2168 | | to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might |
| 2169 | | either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without |
| 2170 | | looking at the body. |
| 2171 | | </p> |
| 2172 | | <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> |
| 2173 | | <ul> |
| 2174 | | <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) with the "100-continue" expectation. |
| 2175 | | </li> |
| 2176 | | <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body. |
| 2177 | | </li> |
| 2178 | | </ul> |
| 2179 | | <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: |
| 2180 | | 100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has |
| 2181 | | never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. |
| 2182 | | </p> |
| 2183 | | <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p> |
| 2184 | | <ul> |
| 2185 | | <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. |
| 2186 | | </li> |
| 2187 | | <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility |
| 2188 | | with <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue" |
| 2189 | | expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared |
| 2190 | | wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value. |
| 2191 | | </li> |
| 2192 | | <li>An origin server <em class="bcp14">MAY</em> omit a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request. |
| 2193 | | </li> |
| 2194 | | <li>An origin server that sends a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection |
| 2195 | | prematurely. |
| 2196 | | </li> |
| 2197 | | <li>If an origin server receives a request that does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final |
| 2198 | | status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, |
| 2199 | | the client might not reliably receive the response message. However, this requirement ought not be construed as preventing |
| 2200 | | a server from defending itself against denial-of-service attacks, or from badly broken client implementations. |
| 2201 | | </li> |
| 2202 | | </ul> |
| 2203 | | <p id="rfc.section.6.4.3.p.5">Requirements for HTTP/1.1 proxies: </p> |
| 2204 | | <ul> |
| 2205 | | <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 |
| 2206 | | or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field. |
| 2207 | | </li> |
| 2208 | | <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code. |
| 2209 | | </li> |
| 2210 | | <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. |
| 2211 | | </li> |
| 2212 | | <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). |
| 2213 | | </li> |
| 2214 | | </ul> |
| 2215 | | <h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a> <a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3> |
| 2216 | | <p id="rfc.section.6.4.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes |
| 2217 | | the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send |
| 2218 | | a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted |
| 2219 | | by the HTTP application. |
| 2220 | | </p> |
| 2221 | | <div id="rfc.iref.u.5"></div> |
| 2222 | | <div id="rfc.iref.h.14"></div> |
| 2223 | | <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> |
| 2224 | | <p id="rfc.section.6.5.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the |
| 2225 | | server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. |
| 2226 | | </p> |
| 2227 | | <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.94"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> |
| | 2182 | by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. |
| | 2183 | </p> |
| | 2184 | </div> |
| | 2185 | <div id="persistent.connections"> |
| | 2186 | <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a href="#persistent.connections">Persistent Connections</a></h2> |
| | 2187 | <div id="persistent.purpose"> |
| | 2188 | <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a href="#persistent.purpose">Purpose</a></h3> |
| | 2189 | <p id="rfc.section.6.3.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers |
| | 2190 | and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make |
| | 2191 | multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a |
| | 2192 | prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. |
| | 2193 | </p> |
| | 2194 | <p id="rfc.section.6.3.1.p.2">Persistent HTTP connections have a number of advantages: </p> |
| | 2195 | <ul> |
| | 2196 | <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, |
| | 2197 | tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts. |
| | 2198 | </li> |
| | 2199 | <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without |
| | 2200 | waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. |
| | 2201 | </li> |
| | 2202 | <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to |
| | 2203 | determine the congestion state of the network. |
| | 2204 | </li> |
| | 2205 | <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li> |
| | 2206 | <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using |
| | 2207 | future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old |
| | 2208 | semantics after an error is reported. |
| | 2209 | </li> |
| | 2210 | </ul> |
| | 2211 | <p id="rfc.section.6.3.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. |
| | 2212 | </p> |
| | 2213 | </div> |
| | 2214 | <div id="persistent.overall"> |
| | 2215 | <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a href="#persistent.overall">Overall Operation</a></h3> |
| | 2216 | <p id="rfc.section.6.3.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior |
| | 2217 | of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server. |
| | 2218 | </p> |
| | 2219 | <p id="rfc.section.6.3.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling |
| | 2220 | takes place using the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. |
| | 2221 | </p> |
| | 2222 | <div id="persistent.negotiation"> |
| | 2223 | <h4 id="rfc.section.6.3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a> <a href="#persistent.negotiation">Negotiation</a></h4> |
| | 2224 | <p id="rfc.section.6.3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection |
| | 2225 | immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". |
| | 2226 | </p> |
| | 2227 | <p id="rfc.section.6.3.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains |
| | 2228 | a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that |
| | 2229 | request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". |
| | 2230 | </p> |
| | 2231 | <p id="rfc.section.6.3.2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection. |
| | 2232 | </p> |
| | 2233 | <p id="rfc.section.6.3.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. |
| | 2234 | </p> |
| | 2235 | <p id="rfc.section.6.3.2.1.p.5">Each persistent connection applies to only one transport link.</p> |
| | 2236 | <p id="rfc.section.6.3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="https://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). |
| | 2237 | </p> |
| | 2238 | <p id="rfc.section.6.3.2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. |
| | 2239 | </p> |
| | 2240 | </div> |
| | 2241 | <div id="pipelining"> |
| | 2242 | <h4 id="rfc.section.6.3.2.2"><a href="#rfc.section.6.3.2.2">6.3.2.2</a> <a href="#pipelining">Pipelining</a></h4> |
| | 2243 | <p id="rfc.section.6.3.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received. |
| | 2244 | </p> |
| | 2245 | <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. |
| | 2246 | </p> |
| | 2247 | <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to |
| | 2248 | send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. |
| | 2249 | </p> |
| | 2250 | </div> |
| | 2251 | </div> |
| | 2252 | <div id="persistent.practical"> |
| | 2253 | <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a> <a href="#persistent.practical">Practical Considerations</a></h3> |
| | 2254 | <p id="rfc.section.6.3.3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers |
| | 2255 | might make this a higher value since it is likely that the client will be making more connections through the same server. |
| | 2256 | The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client |
| | 2257 | or the server. |
| | 2258 | </p> |
| | 2259 | <p id="rfc.section.6.3.3.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does |
| | 2260 | not detect the other side's close promptly it could cause unnecessary resource drain on the network. |
| | 2261 | </p> |
| | 2262 | <p id="rfc.section.6.3.3.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time |
| | 2263 | that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed |
| | 2264 | while it was idle, but from the client's point of view, a request is in progress. |
| | 2265 | </p> |
| | 2266 | <p id="rfc.section.6.3.3.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies). |
| | 2267 | </p> |
| | 2268 | <p id="rfc.section.6.3.3.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many |
| | 2269 | applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages |
| | 2270 | clients to be conservative when opening multiple connections. |
| | 2271 | </p> |
| | 2272 | <p id="rfc.section.6.3.3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant |
| | 2273 | server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used |
| | 2274 | consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side |
| | 2275 | effects in congested networks. |
| | 2276 | </p> |
| | 2277 | <p id="rfc.section.6.3.3.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> |
| | 2278 | </div> |
| | 2279 | <div id="persistent.retrying.requests"> |
| | 2280 | <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a href="#persistent.retrying.requests">Retrying Requests</a></h3> |
| | 2281 | <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request |
| | 2282 | sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding |
| | 2283 | of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. |
| | 2284 | </p> |
| | 2285 | </div> |
| | 2286 | </div> |
| | 2287 | <div id="message.transmission.requirements"> |
| | 2288 | <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a href="#message.transmission.requirements">Message Transmission Requirements</a></h2> |
| | 2289 | <div id="persistent.flow"> |
| | 2290 | <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <a href="#persistent.flow">Persistent Connections and Flow Control</a></h3> |
| | 2291 | <p id="rfc.section.6.4.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating |
| | 2292 | connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. |
| | 2293 | </p> |
| | 2294 | </div> |
| | 2295 | <div id="persistent.monitor"> |
| | 2296 | <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> |
| | 2297 | <p id="rfc.section.6.4.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error |
| | 2298 | status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection. |
| | 2299 | </p> |
| | 2300 | </div> |
| | 2301 | <div id="use.of.the.100.status"> |
| | 2302 | <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> |
| | 2303 | <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing |
| | 2304 | to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might |
| | 2305 | either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without |
| | 2306 | looking at the body. |
| | 2307 | </p> |
| | 2308 | <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> |
| | 2309 | <ul> |
| | 2310 | <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) with the "100-continue" expectation. |
| | 2311 | </li> |
| | 2312 | <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body. |
| | 2313 | </li> |
| | 2314 | </ul> |
| | 2315 | <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: |
| | 2316 | 100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has |
| | 2317 | never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. |
| | 2318 | </p> |
| | 2319 | <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p> |
| | 2320 | <ul> |
| | 2321 | <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. |
| | 2322 | </li> |
| | 2323 | <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility |
| | 2324 | with <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue" |
| | 2325 | expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared |
| | 2326 | wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value. |
| | 2327 | </li> |
| | 2328 | <li>An origin server <em class="bcp14">MAY</em> omit a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request. |
| | 2329 | </li> |
| | 2330 | <li>An origin server that sends a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection |
| | 2331 | prematurely. |
| | 2332 | </li> |
| | 2333 | <li>If an origin server receives a request that does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final |
| | 2334 | status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, |
| | 2335 | the client might not reliably receive the response message. However, this requirement ought not be construed as preventing |
| | 2336 | a server from defending itself against denial-of-service attacks, or from badly broken client implementations. |
| | 2337 | </li> |
| | 2338 | </ul> |
| | 2339 | <p id="rfc.section.6.4.3.p.5">Requirements for HTTP/1.1 proxies: </p> |
| | 2340 | <ul> |
| | 2341 | <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 |
| | 2342 | or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field. |
| | 2343 | </li> |
| | 2344 | <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code. |
| | 2345 | </li> |
| | 2346 | <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. |
| | 2347 | </li> |
| | 2348 | <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). |
| | 2349 | </li> |
| | 2350 | </ul> |
| | 2351 | </div> |
| | 2352 | <div id="closing.connections.on.error"> |
| | 2353 | <h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a> <a href="#closing.connections.on.error">Closing Connections on Error</a></h3> |
| | 2354 | <p id="rfc.section.6.4.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes |
| | 2355 | the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send |
| | 2356 | a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted |
| | 2357 | by the HTTP application. |
| | 2358 | </p> |
| | 2359 | </div> |
| | 2360 | </div> |
| | 2361 | <div id="header.upgrade"> |
| | 2362 | <div id="rfc.iref.u.5"></div> |
| | 2363 | <div id="rfc.iref.h.14"></div> |
| | 2364 | <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a href="#header.upgrade">Upgrade</a></h2> |
| | 2365 | <p id="rfc.section.6.5.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the |
| | 2366 | server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. |
| | 2367 | </p> |
| | 2368 | <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.94"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> |
| 2235 | | protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP |
| 2236 | | with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult |
| 2237 | | transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol |
| 2238 | | while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by |
| 2239 | | the server, possibly according to the nature of the request method or target resource). |
| 2240 | | </p> |
| 2241 | | <p id="rfc.section.6.5.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. |
| 2242 | | Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities |
| 2243 | | and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, |
| 2244 | | although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. |
| 2245 | | </p> |
| 2246 | | <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message. |
| 2247 | | </p> |
| 2248 | | <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it |
| 2249 | | is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). |
| 2250 | | </p> |
| 2251 | | <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching |
| 2252 | | Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. |
| 2253 | | </p> |
| 2254 | | <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 |
| 2255 | | 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 |
| 2256 | | in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. |
| 2257 | | </p> |
| 2258 | | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> |
| 2259 | | <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> |
| 2260 | | <p id="rfc.section.7.1.p.1">HTTP header fields are registered within the Message Header Field Registry <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a> maintained by IANA at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>. |
| 2261 | | </p> |
| 2262 | | <p id="rfc.section.7.1.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to |
| 2263 | | the permanent registrations below: |
| 2264 | | </p> |
| 2265 | | <div id="rfc.table.1"> |
| 2266 | | <div id="iana.header.registration.table"></div> |
| 2267 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| 2268 | | <thead> |
| 2269 | | <tr> |
| 2270 | | <th>Header Field Name</th> |
| 2271 | | <th>Protocol</th> |
| 2272 | | <th>Status</th> |
| 2273 | | <th>Reference</th> |
| 2274 | | </tr> |
| 2275 | | </thead> |
| 2276 | | <tbody> |
| 2277 | | <tr> |
| 2278 | | <td class="left">Connection</td> |
| 2279 | | <td class="left">http</td> |
| 2280 | | <td class="left">standard</td> |
| 2281 | | <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 6.1</a> |
| 2282 | | </td> |
| 2283 | | </tr> |
| 2284 | | <tr> |
| 2285 | | <td class="left">Content-Length</td> |
| 2286 | | <td class="left">http</td> |
| 2287 | | <td class="left">standard</td> |
| 2288 | | <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 3.3.2</a> |
| 2289 | | </td> |
| 2290 | | </tr> |
| 2291 | | <tr> |
| 2292 | | <td class="left">Host</td> |
| 2293 | | <td class="left">http</td> |
| 2294 | | <td class="left">standard</td> |
| 2295 | | <td class="left"> <a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 5.4</a> |
| 2296 | | </td> |
| 2297 | | </tr> |
| 2298 | | <tr> |
| 2299 | | <td class="left">TE</td> |
| 2300 | | <td class="left">http</td> |
| 2301 | | <td class="left">standard</td> |
| 2302 | | <td class="left"> <a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 4.3</a> |
| 2303 | | </td> |
| 2304 | | </tr> |
| 2305 | | <tr> |
| 2306 | | <td class="left">Trailer</td> |
| 2307 | | <td class="left">http</td> |
| 2308 | | <td class="left">standard</td> |
| 2309 | | <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 4.4</a> |
| 2310 | | </td> |
| 2311 | | </tr> |
| 2312 | | <tr> |
| 2313 | | <td class="left">Transfer-Encoding</td> |
| 2314 | | <td class="left">http</td> |
| 2315 | | <td class="left">standard</td> |
| 2316 | | <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 3.3.1</a> |
| 2317 | | </td> |
| 2318 | | </tr> |
| 2319 | | <tr> |
| 2320 | | <td class="left">Upgrade</td> |
| 2321 | | <td class="left">http</td> |
| 2322 | | <td class="left">standard</td> |
| 2323 | | <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.5</a> |
| 2324 | | </td> |
| 2325 | | </tr> |
| 2326 | | <tr> |
| 2327 | | <td class="left">Via</td> |
| 2328 | | <td class="left">http</td> |
| 2329 | | <td class="left">standard</td> |
| 2330 | | <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 6.2</a> |
| 2331 | | </td> |
| 2332 | | </tr> |
| 2333 | | </tbody> |
| 2334 | | </table> |
| | 2376 | protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP |
| | 2377 | with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult |
| | 2378 | transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol |
| | 2379 | while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by |
| | 2380 | the server, possibly according to the nature of the request method or target resource). |
| | 2381 | </p> |
| | 2382 | <p id="rfc.section.6.5.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. |
| | 2383 | Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities |
| | 2384 | and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, |
| | 2385 | although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. |
| | 2386 | </p> |
| | 2387 | <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message. |
| | 2388 | </p> |
| | 2389 | <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it |
| | 2390 | is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). |
| | 2391 | </p> |
| | 2392 | <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching |
| | 2393 | Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em cl |
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)