| 727 | | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> |
| 728 | | <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and |
| 729 | | MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the |
| 730 | | Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource and relationships between resources. Messages are passed in a format similar to that used |
| 731 | | by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). |
| 732 | | </p> |
| 733 | | <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented |
| 734 | | by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do |
| 735 | | not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated |
| 736 | | with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used |
| 737 | | effectively in many different contexts and for which implementations can evolve independently over time. |
| 738 | | </p> |
| 739 | | <p id="rfc.section.1.p.3">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information |
| 740 | | systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols |
| 741 | | into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. |
| 742 | | </p> |
| 743 | | <p id="rfc.section.1.p.4">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, |
| 744 | | we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of |
| 745 | | recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding |
| 746 | | changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps |
| 747 | | at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. |
| 748 | | </p> |
| 749 | | <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, |
| 750 | | describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. |
| 751 | | Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, |
| 752 | | thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. |
| 753 | | </p> |
| 754 | | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> |
| 755 | | <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" |
| 756 | | 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>. |
| 757 | | </p> |
| 758 | | <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, |
| 759 | | Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="#architecture" title="Architecture">Section 2</a> for definitions of these terms. |
| 760 | | </p> |
| 761 | | <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that |
| 762 | | SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. |
| 763 | | </p> |
| 764 | | <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. |
| 765 | | </p> |
| 766 | | <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling |
| 767 | | mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require |
| 768 | | different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the |
| 769 | | Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of |
| 770 | | error recovery could lead to dangerous consequences. |
| 771 | | </p> |
| 772 | | <div id="rfc.iref.g.1"></div> |
| 773 | | <div id="rfc.iref.g.2"></div> |
| 774 | | <div id="rfc.iref.g.3"></div> |
| 775 | | <div id="rfc.iref.g.4"></div> |
| 776 | | <div id="rfc.iref.g.5"></div> |
| 777 | | <div id="rfc.iref.g.6"></div> |
| 778 | | <div id="rfc.iref.g.7"></div> |
| 779 | | <div id="rfc.iref.g.8"></div> |
| 780 | | <div id="rfc.iref.g.9"></div> |
| 781 | | <div id="rfc.iref.g.10"></div> |
| 782 | | <div id="rfc.iref.g.11"></div> |
| 783 | | <div id="rfc.iref.g.12"></div> |
| 784 | | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> |
| 785 | | <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>. |
| 786 | | </p> |
| 787 | | <div id="core.rules"> |
| 788 | | <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 |
| 789 | | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
| 790 | | (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). |
| | 714 | <div id="introduction"> |
| | 715 | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a></h1> |
| | 716 | <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and |
| | 717 | MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the |
| | 718 | Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource and relationships between resources. Messages are passed in a format similar to that used |
| | 719 | by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). |
| 792 | | </div> |
| 793 | | <p id="rfc.section.1.2.p.3">As a syntactic convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical |
| 794 | | reasons. |
| 795 | | </p> |
| 796 | | <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="notation.abnf" href="#notation.abnf">ABNF Extension: #rule</a></h3> |
| 797 | | <p id="rfc.section.1.2.1.p.1">The #rule extension to the ABNF rules of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> is used to improve readability. |
| 798 | | </p> |
| 799 | | <p id="rfc.section.1.2.1.p.2">A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "<n>#<m>element" |
| 800 | | indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS, <a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>). |
| 801 | | </p> |
| 802 | | <div id="rfc.figure.u.1"></div> |
| 803 | | <p>Thus,</p><pre class="text"> 1#element => element *( OWS "," OWS element ) |
| | 721 | <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented |
| | 722 | by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do |
| | 723 | not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated |
| | 724 | with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used |
| | 725 | effectively in many different contexts and for which implementations can evolve independently over time. |
| | 726 | </p> |
| | 727 | <p id="rfc.section.1.p.3">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information |
| | 728 | systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols |
| | 729 | into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. |
| | 730 | </p> |
| | 731 | <p id="rfc.section.1.p.4">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, |
| | 732 | we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of |
| | 733 | recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding |
| | 734 | changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps |
| | 735 | at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. |
| | 736 | </p> |
| | 737 | <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, |
| | 738 | describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. |
| | 739 | Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, |
| | 740 | thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. |
| | 741 | </p> |
| | 742 | <div id="intro.conformance.and.error.handling"> |
| | 743 | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> |
| | 744 | <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" |
| | 745 | 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>. |
| | 746 | </p> |
| | 747 | <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, |
| | 748 | Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="#architecture" title="Architecture">Section 2</a> for definitions of these terms. |
| | 749 | </p> |
| | 750 | <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that |
| | 751 | SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. |
| | 752 | </p> |
| | 753 | <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. |
| | 754 | </p> |
| | 755 | <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling |
| | 756 | mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require |
| | 757 | different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the |
| | 758 | Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of |
| | 759 | error recovery could lead to dangerous consequences. |
| | 760 | </p> |
| | 761 | </div> |
| | 762 | <div id="notation"> |
| | 763 | <div id="rfc.iref.g.1"></div> |
| | 764 | <div id="rfc.iref.g.2"></div> |
| | 765 | <div id="rfc.iref.g.3"></div> |
| | 766 | <div id="rfc.iref.g.4"></div> |
| | 767 | <div id="rfc.iref.g.5"></div> |
| | 768 | <div id="rfc.iref.g.6"></div> |
| | 769 | <div id="rfc.iref.g.7"></div> |
| | 770 | <div id="rfc.iref.g.8"></div> |
| | 771 | <div id="rfc.iref.g.9"></div> |
| | 772 | <div id="rfc.iref.g.10"></div> |
| | 773 | <div id="rfc.iref.g.11"></div> |
| | 774 | <div id="rfc.iref.g.12"></div> |
| | 775 | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a href="#notation">Syntax Notation</a></h2> |
| | 776 | <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>. |
| | 777 | </p> |
| | 778 | <div id="core.rules"> |
| | 779 | <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="https://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 |
| | 780 | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
| | 781 | (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). |
| | 782 | </p> |
| | 783 | </div> |
| | 784 | <p id="rfc.section.1.2.p.3">As a syntactic convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical |
| | 785 | reasons. |
| | 786 | </p> |
| | 787 | <div id="notation.abnf"> |
| | 788 | <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a href="#notation.abnf">ABNF Extension: #rule</a></h3> |
| | 789 | <p id="rfc.section.1.2.1.p.1">The #rule extension to the ABNF rules of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> is used to improve readability. |
| | 790 | </p> |
| | 791 | <p id="rfc.section.1.2.1.p.2">A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "<n>#<m>element" |
| | 792 | indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS, <a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>). |
| | 793 | </p> |
| | 794 | <div id="rfc.figure.u.1"></div> |
| | 795 | <p>Thus,</p><pre class="text"> 1#element => element *( OWS "," OWS element ) |
| 923 | | </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="message-orientation-and-buffering" href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2> |
| 924 | | <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations |
| 925 | | only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some |
| 926 | | amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide |
| 927 | | other services. |
| 928 | | </p> |
| 929 | | <p id="rfc.section.2.2.p.2">Therefore, extensions to and uses of HTTP cannot rely on the availability of a partial message, or assume that messages will |
| 930 | | not be buffered. There are strategies that can be used to test for buffering in a given connection, but it should be understood |
| 931 | | that behaviors can differ across connections, and between requests and responses. |
| 932 | | </p> |
| 933 | | <p id="rfc.section.2.2.p.3">Recipients <em class="bcp14">MUST</em> consider every message in a connection in isolation; because HTTP is a stateless protocol, it cannot be assumed that two requests |
| 934 | | on the same connection are from the same client or share any other common attributes. In particular, intermediaries might |
| 935 | | mix requests from different clients into a single server connection. Note that some existing 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>) violate this requirement, thereby potentially causing interoperability and security problems. |
| 936 | | </p> |
| 937 | | <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> |
| 938 | | <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 |
| 939 | | transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request |
| 940 | | and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. |
| 941 | | </p> |
| 942 | | <p id="rfc.section.2.3.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's |
| 943 | | URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use |
| 944 | | a proxy via some other connection port or protocol instead of using the defaults. |
| 945 | | </p> |
| 946 | | <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.1</a>. |
| 947 | | </p> |
| 948 | | <div id="rfc.iref.i.1"></div> |
| 949 | | <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> |
| 950 | | <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 |
| 951 | | HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, |
| 952 | | switching behavior based on the nature of each request. |
| 953 | | </p> |
| 954 | | <div id="rfc.figure.u.12"></div><pre class="drawing"> > > > > |
| | 922 | </span></pre></div> |
| | 923 | <div id="message-orientation-and-buffering"> |
| | 924 | <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2> |
| | 925 | <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations |
| | 926 | only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some |
| | 927 | amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide |
| | 928 | other services. |
| | 929 | </p> |
| | 930 | <p id="rfc.section.2.2.p.2">Therefore, extensions to and uses of HTTP cannot rely on the availability of a partial message, or assume that messages will |
| | 931 | not be buffered. There are strategies that can be used to test for buffering in a given connection, but it should be understood |
| | 932 | that behaviors can differ across connections, and between requests and responses. |
| | 933 | </p> |
| | 934 | <p id="rfc.section.2.2.p.3">Recipients <em class="bcp14">MUST</em> consider every message in a connection in isolation; because HTTP is a stateless protocol, it cannot be assumed that two requests |
| | 935 | on the same connection are from the same client or share any other common attributes. In particular, intermediaries might |
| | 936 | mix requests from different clients into a single server connection. Note that some existing 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>) violate this requirement, thereby potentially causing interoperability and security problems. |
| | 937 | </p> |
| | 938 | </div> |
| | 939 | <div id="transport-independence"> |
| | 940 | <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> |
| | 941 | <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 |
| | 942 | transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request |
| | 943 | and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. |
| | 944 | </p> |
| | 945 | <p id="rfc.section.2.3.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's |
| | 946 | URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use |
| | 947 | a proxy via some other connection port or protocol instead of using the defaults. |
| | 948 | </p> |
| | 949 | <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.1</a>. |
| | 950 | </p> |
| | 951 | </div> |
| | 952 | <div id="intermediaries"> |
| | 953 | <div id="rfc.iref.i.1"></div> |
| | 954 | <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a href="#intermediaries">Intermediaries</a></h2> |
| | 955 | <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 |
| | 956 | HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, |
| | 957 | switching behavior based on the nature of each request. |
| | 958 | </p> |
| | 959 | <div id="rfc.figure.u.12"></div><pre class="drawing"> > > > > |
| 958 | | message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply |
| 959 | | only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along |
| 960 | | the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For |
| 961 | | example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, |
| 962 | | at the same time that it is handling A's request. |
| 963 | | </p> |
| 964 | | <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. |
| 965 | | 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. |
| 966 | | </p> |
| 967 | | <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 |
| 968 | | for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations |
| 969 | | are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely |
| 970 | | different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary |
| 971 | | for the sake of security, annotation services, or shared caching. |
| 972 | | </p> |
| 973 | | <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, |
| 974 | | beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original |
| 975 | | sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared |
| 976 | | annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, |
| 977 | | or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) |
| 978 | | that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform |
| 979 | | 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 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. |
| 980 | | </p> |
| 981 | | <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.16"></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 |
| 982 | | server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance |
| 983 | | through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. |
| 984 | | </p> |
| 985 | | <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 |
| 986 | | applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound |
| 987 | | servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. |
| 988 | | However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.8</a>) header fields for both connections. |
| 989 | | </p> |
| 990 | | <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 |
| 991 | | to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both |
| 992 | | ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as |
| 993 | | when transport-layer security is used to establish private communication through a shared firewall proxy. |
| 994 | | </p> |
| 995 | | <p id="rfc.section.2.4.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless |
| 996 | | act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a |
| 997 | | mess of things). Such a network intermediary, often referred to as an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "<dfn>captive portal</dfn>", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects |
| 998 | | outgoing TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception proxies |
| 999 | | are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of |
| 1000 | | non-local Internet services, and within corporate firewalls to enforce network usage policies. They are indistinguishable |
| 1001 | | from a man-in-the-middle attack. |
| 1002 | | </p> |
| 1003 | | <div id="rfc.iref.c.4"></div> |
| 1004 | | <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="caches" href="#caches">Caches</a></h2> |
| 1005 | | <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. |
| 1006 | | A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent |
| 1007 | | 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. |
| 1008 | | </p> |
| 1009 | | <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 |
| 1010 | | response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response |
| 1011 | | from O (via C) for a request which has not been cached by UA or A. |
| 1012 | | </p> |
| 1013 | | <div id="rfc.figure.u.13"></div><pre class="drawing"> > > |
| | 963 | message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply |
| | 964 | only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along |
| | 965 | the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For |
| | 966 | example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, |
| | 967 | at the same time that it is handling A's request. |
| | 968 | </p> |
| | 969 | <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. |
| | 970 | 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. |
| | 971 | </p> |
| | 972 | <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 |
| | 973 | for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations |
| | 974 | are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely |
| | 975 | different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary |
| | 976 | for the sake of security, annotation services, or shared caching. |
| | 977 | </p> |
| | 978 | <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, |
| | 979 | beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original |
| | 980 | sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared |
| | 981 | annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, |
| | 982 | or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) |
| | 983 | that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform |
| | 984 | 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 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. |
| | 985 | </p> |
| | 986 | <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.16"></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 |
| | 987 | server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance |
| | 988 | through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. |
| | 989 | </p> |
| | 990 | <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 |
| | 991 | applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound |
| | 992 | servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. |
| | 993 | However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.8</a>) header fields for both connections. |
| | 994 | </p> |
| | 995 | <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 |
| | 996 | to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both |
| | 997 | ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as |
| | 998 | when transport-layer security is used to establish private communication through a shared firewall proxy. |
| | 999 | </p> |
| | 1000 | <p id="rfc.section.2.4.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless |
| | 1001 | act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a |
| | 1002 | mess of things). Such a network intermediary, often referred to as an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "<dfn>captive portal</dfn>", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects |
| | 1003 | outgoing TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception proxies |
| | 1004 | are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of |
| | 1005 | non-local Internet services, and within corporate firewalls to enforce network usage policies. They are indistinguishable |
| | 1006 | from a man-in-the-middle attack. |
| | 1007 | </p> |
| | 1008 | </div> |
| | 1009 | <div id="caches"> |
| | 1010 | <div id="rfc.iref.c.4"></div> |
| | 1011 | <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a href="#caches">Caches</a></h2> |
| | 1012 | <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. |
| | 1013 | A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent |
| | 1014 | 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. |
| | 1015 | </p> |
| | 1016 | <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 |
| | 1017 | response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response |
| | 1018 | from O (via C) for a request which has not been cached by UA or A. |
| | 1019 | </p> |
| | 1020 | <div id="rfc.figure.u.13"></div><pre class="drawing"> > > |
| 1034 | | version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version |
| 1035 | | to which the sender is at least conditionally compliant and able to understand for future communication. The minor version |
| 1036 | | advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the |
| 1037 | | protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future |
| 1038 | | requests (by clients). |
| 1039 | | </p> |
| 1040 | | <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 |
| 1041 | | message if all of the newer features are ignored. This specification places recipient-version requirements on some new features |
| 1042 | | so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt |
| 1043 | | of a message, that the recipient supports HTTP/1.1. |
| 1044 | | </p> |
| 1045 | | <p id="rfc.section.2.6.p.6">The interpretation of an HTTP header field does not change between minor versions of the same major version, though the default |
| 1046 | | behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 |
| 1047 | | are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by |
| 1048 | | all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1. |
| 1049 | | </p> |
| 1050 | | <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation |
| 1051 | | 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 |
| 1052 | | by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. |
| 1053 | | </p> |
| 1054 | | <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary |
| 1055 | | understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP |
| 1056 | | message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message |
| 1057 | | sender's version to determine what features are safe to use for later communication with that sender. |
| 1058 | | </p> |
| 1059 | | <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major |
| 1060 | | version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. |
| 1061 | | </p> |
| 1062 | | <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after |
| 1063 | | the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server) |
| 1064 | | that the server improperly handles higher request versions. |
| 1065 | | </p> |
| 1066 | | <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major |
| 1067 | | version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's |
| 1068 | | request. |
| 1069 | | </p> |
| 1070 | | <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP |
| 1071 | | specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version |
| 1072 | | number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the |
| 1073 | | 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., |
| 1074 | | User-Agent) uniquely match the values sent by a client known to be in error. |
| 1075 | | </p> |
| 1076 | | <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax |
| 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.3"><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 id="rfc.iref.r.5"></div> |
| 1082 | | <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> |
| 1083 | | <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects, |
| 1084 | | and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to |
| 1085 | | 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>. |
| 1086 | | </p> |
| 1087 | | <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| 1088 | | "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. |
| 1089 | | </p> |
| 1090 | | <div id="rfc.figure.u.15"></div><pre class="inline"><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><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></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>> |
| 1091 | | <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>> |
| 1092 | | <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>> |
| 1093 | | <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>> |
| 1094 | | <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>> |
| 1095 | | <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>> |
| 1096 | | <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>> |
| 1097 | | <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>> |
| 1098 | | <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>> |
| | 1043 | version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version |
| | 1044 | to which the sender is at least conditionally compliant and able to understand for future communication. The minor version |
| | 1045 | advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the |
| | 1046 | protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future |
| | 1047 | requests (by clients). |
| | 1048 | </p> |
| | 1049 | <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 |
| | 1050 | message if all of the newer features are ignored. This specification places recipient-version requirements on some new features |
| | 1051 | so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt |
| | 1052 | of a message, that the recipient supports HTTP/1.1. |
| | 1053 | </p> |
| | 1054 | <p id="rfc.section.2.6.p.6">The interpretation of an HTTP header field does not change between minor versions of the same major version, though the default |
| | 1055 | behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 |
| | 1056 | are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by |
| | 1057 | all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1. |
| | 1058 | </p> |
| | 1059 | <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation |
| | 1060 | 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 |
| | 1061 | by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. |
| | 1062 | </p> |
| | 1063 | <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary |
| | 1064 | understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP |
| | 1065 | message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message |
| | 1066 | sender's version to determine what features are safe to use for later communication with that sender. |
| | 1067 | </p> |
| | 1068 | <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major |
| | 1069 | version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. |
| | 1070 | </p> |
| | 1071 | <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after |
| | 1072 | the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server) |
| | 1073 | that the server improperly handles higher request versions. |
| | 1074 | </p> |
| | 1075 | <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major |
| | 1076 | version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's |
| | 1077 | request. |
| | 1078 | </p> |
| | 1079 | <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP |
| | 1080 | specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version |
| | 1081 | number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the |
| | 1082 | 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., |
| | 1083 | User-Agent) uniquely match the values sent by a client known to be in error. |
| | 1084 | </p> |
| | 1085 | <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax |
| | 1086 | is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding |
| | 1087 | to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented |
| | 1088 | 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.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol. |
| | 1089 | </p> |
| | 1090 | </div> |
| | 1091 | <div id="uri"> |
| | 1092 | <div id="rfc.iref.r.5"></div> |
| | 1093 | <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a href="#uri">Uniform Resource Identifiers</a></h2> |
| | 1094 | <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects, |
| | 1095 | and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to |
| | 1096 | 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>. |
| | 1097 | </p> |
| | 1098 | <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", |
| | 1099 | "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. |
| | 1100 | </p> |
| | 1101 | <div id="rfc.figure.u.15"></div><pre class="inline"><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><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></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>> |
| | 1102 | <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>> |
| | 1103 | <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>> |
| | 1104 | <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>> |
| | 1105 | <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>> |
| | 1106 | <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>> |
| | 1107 | <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>> |
| | 1108 | <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>> |
| | 1109 | <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>> |
| 1102 | | any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, |
| 1103 | | or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request |
| 1104 | | URI, which defines the default base URI for references in both the request and its corresponding response. |
| 1105 | | </p> |
| 1106 | | <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a> <a id="http.uri" href="#http.uri">http URI scheme</a></h3> |
| 1107 | | <div id="rfc.iref.h.1"></div> |
| 1108 | | <div id="rfc.iref.u.3"></div> |
| 1109 | | <p id="rfc.section.2.7.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical |
| 1110 | | namespace governed by a potential HTTP origin server listening for TCP connections on a given port. |
| 1111 | | </p> |
| 1112 | | <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.26"></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> ] |
| 1113 | | </pre><p id="rfc.section.2.7.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an |
| 1114 | | identifier for a potential resource within that origin server's name space. |
| 1115 | | </p> |
| 1116 | | <p id="rfc.section.2.7.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated |
| 1117 | | TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient |
| 1118 | | 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 |
| 1119 | | port for WWW services). |
| 1120 | | </p> |
| 1121 | | <p id="rfc.section.2.7.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address. |
| 1122 | | The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening |
| 1123 | | to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish |
| 1124 | | a naming authority (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that |
| 1125 | | authority to determine which names are valid and how they might be used. |
| 1126 | | </p> |
| 1127 | | <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, |
| 1128 | | 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 4</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.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. |
| 1129 | | </p> |
| 1130 | | <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name |
| 1131 | | delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol |
| 1132 | | would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require |
| 1133 | | an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources |
| 1134 | | — it is only the authoritative interface used for mapping the namespace that is specific to TCP. |
| 1135 | | </p> |
| 1136 | | <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal |
| 1137 | | configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, |
| 1138 | | 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 |
| 1139 | | 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 |
| 1140 | | is being used to obscure the authority for the sake of phishing attacks. |
| 1141 | | </p> |
| 1142 | | <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a> <a id="https.uri" href="#https.uri">https URI scheme</a></h3> |
| 1143 | | <div id="rfc.iref.h.2"></div> |
| 1144 | | <div id="rfc.iref.u.4"></div> |
| 1145 | | <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical |
| 1146 | | namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. |
| 1147 | | </p> |
| 1148 | | <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default |
| 1149 | | 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. |
| 1150 | | </p> |
| 1151 | | <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.27"></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> ] |
| | 1113 | any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, |
| | 1114 | or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request |
| | 1115 | URI, which defines the default base URI for references in both the request and its corresponding response. |
| | 1116 | </p> |
| | 1117 | <div id="http.uri"> |
| | 1118 | <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a> <a href="#http.uri">http URI scheme</a></h3> |
| | 1119 | <div id="rfc.iref.h.1"></div> |
| | 1120 | <div id="rfc.iref.u.3"></div> |
| | 1121 | <p id="rfc.section.2.7.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical |
| | 1122 | namespace governed by a potential HTTP origin server listening for TCP connections on a given port. |
| | 1123 | </p> |
| | 1124 | <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.26"></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> ] |
| | 1125 | </pre><p id="rfc.section.2.7.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="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 |
| | 1126 | identifier for a potential resource within that origin server's name space. |
| | 1127 | </p> |
| | 1128 | <p id="rfc.section.2.7.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated |
| | 1129 | TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient |
| | 1130 | 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 |
| | 1131 | port for WWW services). |
| | 1132 | </p> |
| | 1133 | <p id="rfc.section.2.7.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address. |
| | 1134 | The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening |
| | 1135 | to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish |
| | 1136 | a naming authority (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that |
| | 1137 | authority to determine which names are valid and how they might be used. |
| | 1138 | </p> |
| | 1139 | <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, |
| | 1140 | 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 4</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.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. |
| | 1141 | </p> |
| | 1142 | <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name |
| | 1143 | delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol |
| | 1144 | would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require |
| | 1145 | an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources |
| | 1146 | — it is only the authoritative interface used for mapping the namespace that is specific to TCP. |
| | 1147 | </p> |
| | 1148 | <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="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 |
| | 1149 | configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, |
| | 1150 | 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 |
| | 1151 | 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 |
| | 1152 | is being used to obscure the authority for the sake of phishing attacks. |
| | 1153 | </p> |
| | 1154 | </div> |
| | 1155 | <div id="https.uri"> |
| | 1156 | <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a> <a href="#https.uri">https URI scheme</a></h3> |
| | 1157 | <div id="rfc.iref.h.2"></div> |
| | 1158 | <div id="rfc.iref.u.4"></div> |
| | 1159 | <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical |
| | 1160 | namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port. |
| | 1161 | </p> |
| | 1162 | <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default |
| | 1163 | 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. |
| | 1164 | </p> |
| | 1165 | <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.27"></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> ] |
| 1263 | | the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. |
| 1264 | | </p> |
| 1265 | | <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 |
| 1266 | | new semantics, or on the number of header fields used in a given message. Existing fields are defined in each part of this |
| 1267 | | specification and in many other specifications outside the standards process. New header fields can be introduced without |
| 1268 | | changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize |
| 1269 | | them. |
| 1270 | | </p> |
| 1271 | | <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.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.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. |
| 1272 | | </p> |
| 1273 | | <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" |
| 1274 | | to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations |
| 1275 | | 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 |
| 1276 | | conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. |
| 1277 | | </p> |
| 1278 | | <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)]. |
| 1279 | | Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing |
| 1280 | | the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by |
| 1281 | | a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation |
| 1282 | | of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. |
| 1283 | | </p> |
| 1284 | | <div class="note" id="rfc.section.3.2.p.8"> |
| 1285 | | <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 |
| 1286 | | 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. |
| 1287 | | </p> |
| 1288 | | </div> |
| 1289 | | <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3> |
| 1290 | | <p id="rfc.section.3.2.1.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace |
| 1291 | | have led to security vulnerabilities in request routing and response handling. Any received request message that contains |
| 1292 | | whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. |
| 1293 | | </p> |
| 1294 | | <p id="rfc.section.3.2.1.p.2">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing |
| 1295 | | white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet |
| 1296 | | of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field). |
| 1297 | | </p> |
| 1298 | | <p id="rfc.section.3.2.1.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one |
| 1299 | | space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type |
| 1300 | | (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the |
| 1301 | | message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets |
| 1302 | | (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream. |
| 1303 | | </p> |
| 1304 | | <p id="rfc.section.3.2.1.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data. |
| 1305 | | </p> |
| 1306 | | <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.length" href="#field.length">Field Length</a></h3> |
| 1307 | | <p id="rfc.section.3.2.2.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header |
| 1308 | | field(s) would be longer than the server wishes to handle. |
| 1309 | | </p> |
| 1310 | | <p id="rfc.section.3.2.2.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p> |
| 1311 | | <p id="rfc.section.3.2.2.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets. |
| 1312 | | </p> |
| 1313 | | <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="field.rules" href="#field.rules">Common Field ABNF Rules</a></h3> |
| 1314 | | <div id="rule.token.separators"> |
| 1315 | | <p id="rfc.section.3.2.3.p.1"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. |
| 1316 | | These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). |
| 1317 | | </p> |
| 1318 | | </div> |
| 1319 | | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span> <a href="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> |
| | 1298 | the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. |
| | 1299 | </p> |
| | 1300 | <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 |
| | 1301 | new semantics, or on the number of header fields used in a given message. Existing fields are defined in each part of this |
| | 1302 | specification and in many other specifications outside the standards process. New header fields can be introduced without |
| | 1303 | changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize |
| | 1304 | them. |
| | 1305 | </p> |
| | 1306 | <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.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.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. |
| | 1307 | </p> |
| | 1308 | <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" |
| | 1309 | to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations |
| | 1310 | 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 |
| | 1311 | conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. |
| | 1312 | </p> |
| | 1313 | <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)]. |
| | 1314 | Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing |
| | 1315 | the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by |
| | 1316 | a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation |
| | 1317 | of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. |
| | 1318 | </p> |
| | 1319 | <div class="note" id="rfc.section.3.2.p.8"> |
| | 1320 | <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 |
| | 1321 | 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. |
| | 1322 | </p> |
| | 1323 | </div> |
| | 1324 | <div id="field.parsing"> |
| | 1325 | <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#field.parsing">Field Parsing</a></h3> |
| | 1326 | <p id="rfc.section.3.2.1.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace |
| | 1327 | have led to security vulnerabilities in request routing and response handling. Any received request message that contains |
| | 1328 | whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. |
| | 1329 | </p> |
| | 1330 | <p id="rfc.section.3.2.1.p.2">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing |
| | 1331 | white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet |
| | 1332 | of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field). |
| | 1333 | </p> |
| | 1334 | <p id="rfc.section.3.2.1.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one |
| | 1335 | space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type |
| | 1336 | (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the |
| | 1337 | message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets |
| | 1338 | (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream. |
| | 1339 | </p> |
| | 1340 | <p id="rfc.section.3.2.1.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data. |
| | 1341 | </p> |
| | 1342 | </div> |
| | 1343 | <div id="field.length"> |
| | 1344 | <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#field.length">Field Length</a></h3> |
| | 1345 | <p id="rfc.section.3.2.2.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header |
| | 1346 | field(s) would be longer than the server wishes to handle. |
| | 1347 | </p> |
| | 1348 | <p id="rfc.section.3.2.2.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p> |
| | 1349 | <p id="rfc.section.3.2.2.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets. |
| | 1350 | </p> |
| | 1351 | </div> |
| | 1352 | <div id="field.rules"> |
| | 1353 | <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#field.rules">Common Field ABNF Rules</a></h3> |
| | 1354 | <div id="rule.token.separators"> |
| | 1355 | <p id="rfc.section.3.2.3.p.1"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. |
| | 1356 | These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). |
| | 1357 | </p> |
| | 1358 | </div> |
| | 1359 | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span> <a href="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> |
| 1353 | | <p id="rfc.section.3.2.3.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> |
| | 1393 | <p id="rfc.section.3.2.3.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> |
| | 1394 | </div> |
| | 1395 | <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.50"></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> ) |
| | 1396 | </pre><p id="rfc.section.3.2.3.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 |
| | 1397 | ")"). |
| | 1398 | </p> |
| | 1399 | </div> |
| | 1400 | </div> |
| | 1401 | <div id="message.body"> |
| | 1402 | <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a href="#message.body">Message Body</a></h2> |
| | 1403 | <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p> |
| | 1404 | <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET |
| | 1405 | </pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding |
| | 1406 | header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8.6</a>). 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. |
| | 1407 | </p> |
| | 1408 | <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header |
| | 1409 | field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. 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 under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>. |
| | 1410 | </p> |
| | 1411 | <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 8.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing |
| | 1412 | a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields |
| | 1413 | have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing |
| | 1414 | that decimal value prior to determining the message-body length. |
| | 1415 | </p> |
| | 1416 | <p id="rfc.section.3.3.p.6">The rules for when a message-body is allowed in a message differ for requests and responses.</p> |
| | 1417 | <p id="rfc.section.3.3.p.7">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field |
| | 1418 | in the request's header fields, even if the request method does not define any use for a message-body. This allows the request |
| | 1419 | message framing algorithm to be independent of method semantics. |
| | 1420 | </p> |
| | 1421 | <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and |
| | 1422 | the response status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g., |
| | 1423 | Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. |
| | 1424 | All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 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. |
| | 1425 | </p> |
| | 1426 | <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p> |
| | 1427 | <p id="rfc.section.3.3.p.10"></p> |
| | 1428 | <ol> |
| | 1429 | <li> |
| | 1430 | <p>Any response to a HEAD request and any response with a status code of 100-199, 204, or 304 is always terminated by the first |
| | 1431 | empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message-body. |
| | 1432 | </p> |
| | 1433 | </li> |
| | 1434 | <li> |
| | 1435 | <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding |
| | 1436 | indicates the data is complete. |
| | 1437 | </p> |
| | 1438 | <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding, |
| | 1439 | the message-body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header |
| | 1440 | field is present in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot |
| | 1441 | be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection. |
| | 1442 | </p> |
| | 1443 | <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding |
| | 1444 | overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of |
| | 1445 | security-related checks on message routing or content) and thus ought to be handled as an 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 |
| | 1446 | is decoded. |
| | 1447 | </p> |
| | 1448 | </li> |
| | 1449 | <li> |
| | 1450 | <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing |
| | 1451 | field-values or a single Content-Length header field having an invalid value, then the message 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 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy, |
| | 1452 | the proxy <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection. |
| | 1453 | If this is a response message received by a user-agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection. |
| | 1454 | </p> |
| | 1455 | </li> |
| | 1456 | <li> |
| | 1457 | <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message-body length |
| | 1458 | in octets. If the actual number of octets sent in the message is less 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 |
| | 1459 | 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 |
| | 1460 | and the connection has been closed by the server. |
| | 1461 | </p> |
| | 1462 | </li> |
| | 1463 | <li> |
| | 1464 | <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> |
| | 1465 | </li> |
| | 1466 | <li> |
| | 1467 | <p>Otherwise, this is a response message without a declared message-body length, so the message-body length is determined by |
| | 1468 | the number of octets received prior to the server closing the connection. |
| | 1469 | </p> |
| | 1470 | </li> |
| | 1471 | </ol> |
| | 1472 | <p id="rfc.section.3.3.p.11">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted |
| | 1473 | 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 |
| | 1474 | with HTTP/1.0. |
| | 1475 | </p> |
| | 1476 | <p id="rfc.section.3.3.p.12">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required). |
| | 1477 | </p> |
| | 1478 | <p id="rfc.section.3.3.p.13">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 Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding, |
| | 1479 | since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the |
| | 1480 | chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in |
| | 1481 | advance of being called and the server is unable or unwilling to buffer the entire request before processing. |
| | 1482 | </p> |
| | 1483 | <p id="rfc.section.3.3.p.14">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such |
| | 1484 | knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. |
| | 1485 | </p> |
| | 1486 | </div> |
| | 1487 | <div id="incomplete.messages"> |
| | 1488 | <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a href="#incomplete.messages">Handling Incomplete Messages</a></h2> |
| | 1489 | <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a cancelled 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>. |
| | 1490 | </p> |
| | 1491 | <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 |
| | 1492 | 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) |
| | 1493 | cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error. |
| | 1494 | </p> |
| | 1495 | <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 |
| | 1496 | has not been received. A message that uses a valid Content-Length is incomplete if the size of the message-body received (in |
| | 1497 | octets) is less than the value given by Content-Length. A response that has neither chunked transfer encoding nor Content-Length |
| | 1498 | is terminated by closure of the connection, and thus is considered complete regardless of the number of message-body octets |
| | 1499 | received, provided that the header block was received intact. |
| | 1500 | </p> |
| | 1501 | <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 must be given to the user that an |
| | 1502 | error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| | 1503 | </p> |
| | 1504 | <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 |
| | 1505 | 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 |
| | 1506 | requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.1.2.2</a>. |
| | 1507 | </p> |
| | 1508 | </div> |
| | 1509 | <div id="message.robustness"> |
| | 1510 | <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a href="#message.robustness">Message Parsing Robustness</a></h2> |
| | 1511 | <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 |
| | 1512 | 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 |
| | 1513 | the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length. |
| | 1514 | </p> |
| | 1515 | <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 |
| | 1516 | 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 |
| | 1517 | that recipients recognize a single LF as a line terminator and ignore any CR. |
| | 1518 | </p> |
| | 1519 | <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 |
| | 1520 | message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed |
| | 1521 | above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response. |
| | 1522 | </p> |
| | 1523 | </div> |
| 1355 | | <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.50"></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> ) |
| 1356 | | </pre><p id="rfc.section.3.2.3.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 |
| 1357 | | ")"). |
| 1358 | | </p> |
| 1359 | | <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> |
| 1360 | | <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p> |
| 1361 | | <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET |
| 1362 | | </pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding |
| 1363 | | header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8.6</a>). 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. |
| 1364 | | </p> |
| 1365 | | <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header |
| 1366 | | field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. 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 under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>. |
| 1367 | | </p> |
| 1368 | | <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 8.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing |
| 1369 | | a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields |
| 1370 | | have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing |
| 1371 | | that decimal value prior to determining the message-body length. |
| 1372 | | </p> |
| 1373 | | <p id="rfc.section.3.3.p.6">The rules for when a message-body is allowed in a message differ for requests and responses.</p> |
| 1374 | | <p id="rfc.section.3.3.p.7">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field |
| 1375 | | in the request's header fields, even if the request method does not define any use for a message-body. This allows the request |
| 1376 | | message framing algorithm to be independent of method semantics. |
| 1377 | | </p> |
| 1378 | | <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and |
| 1379 | | the response status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g., |
| 1380 | | Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. |
| 1381 | | All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 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. |
| 1382 | | </p> |
| 1383 | | <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p> |
| 1384 | | <p id="rfc.section.3.3.p.10"> </p> |
| 1385 | | <ol> |
| 1386 | | <li> |
| 1387 | | <p>Any response to a HEAD request and any response with a status code of 100-199, 204, or 304 is always terminated by the first |
| 1388 | | empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message-body. |
| 1389 | | </p> |
| 1390 | | </li> |
| 1391 | | <li> |
| 1392 | | <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding |
| 1393 | | indicates the data is complete. |
| 1394 | | </p> |
| 1395 | | <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding, |
| 1396 | | the message-body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header |
| 1397 | | field is present in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot |
| 1398 | | be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection. |
| 1399 | | </p> |
| 1400 | | <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding |
| 1401 | | overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of |
| 1402 | | security-related checks on message routing or content) and thus ought to be handled as an 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 |
| 1403 | | is decoded. |
| 1404 | | </p> |
| 1405 | | </li> |
| 1406 | | <li> |
| 1407 | | <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing |
| 1408 | | field-values or a single Content-Length header field having an invalid value, then the message 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 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy, |
| 1409 | | the proxy <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection. |
| 1410 | | If this is a response message received by a user-agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection. |
| 1411 | | </p> |
| 1412 | | </li> |
| 1413 | | <li> |
| 1414 | | <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message-body length |
| 1415 | | in octets. If the actual number of octets sent in the message is less 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 |
| 1416 | | 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 |
| 1417 | | and the connection has been closed by the server. |
| 1418 | | </p> |
| 1419 | | </li> |
| 1420 | | <li> |
| 1421 | | <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> |
| 1422 | | </li> |
| 1423 | | <li> |
| 1424 | | <p>Otherwise, this is a response message without a declared message-body length, so the message-body length is determined by |
| 1425 | | the number of octets received prior to the server closing the connection. |
| 1426 | | </p> |
| 1427 | | </li> |
| 1428 | | </ol> |
| 1429 | | <p id="rfc.section.3.3.p.11">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted |
| 1430 | | 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 |
| 1431 | | with HTTP/1.0. |
| 1432 | | </p> |
| 1433 | | <p id="rfc.section.3.3.p.12">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required). |
| 1434 | | </p> |
| 1435 | | <p id="rfc.section.3.3.p.13">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 Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding, |
| 1436 | | since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the |
| 1437 | | chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in |
| 1438 | | advance of being called and the server is unable or unwilling to buffer the entire request before processing. |
| 1439 | | </p> |
| 1440 | | <p id="rfc.section.3.3.p.14">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such |
| 1441 | | knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. |
| 1442 | | </p> |
| 1443 | | <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> |
| 1444 | | <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a cancelled 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>. |
| 1445 | | </p> |
| 1446 | | <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 |
| 1447 | | 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) |
| 1448 | | cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error. |
| 1449 | | </p> |
| 1450 | | <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 |
| 1451 | | has not been received. A message that uses a valid Content-Length is incomplete if the size of the message-body received (in |
| 1452 | | octets) is less than the value given by Content-Length. A response that has neither chunked transfer encoding nor Content-Length |
| 1453 | | is terminated by closure of the connection, and thus is considered complete regardless of the number of message-body octets |
| 1454 | | received, provided that the header block was received intact. |
| 1455 | | </p> |
| 1456 | | <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 must be given to the user that an |
| 1457 | | error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| 1458 | | </p> |
| 1459 | | <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 |
| 1460 | | 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 |
| 1461 | | requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.1.2.2</a>. |
| 1462 | | </p> |
| 1463 | | <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> |
| 1464 | | <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 |
| 1465 | | 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 |
| 1466 | | the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length. |
| 1467 | | </p> |
| 1468 | | <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 |
| 1469 | | 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 |
| 1470 | | that recipients recognize a single LF as a line terminator and ignore any CR. |
| 1471 | | </p> |
| 1472 | | <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 |
| 1473 | | message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed |
| 1474 | | above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response. |
| 1475 | | </p> |
| 1476 | | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> |
| 1477 | | <p id="rfc.section.4.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target |
| 1478 | | resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target. |
| 1479 | | </p> |
| 1480 | | <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2> |
| 1481 | | <p id="rfc.section.4.1.p.1">The four options for request-target are dependent on the nature of the request.</p> |
| 1482 | | <div id="asterix-form"> |
| 1483 | | <p id="rfc.section.4.1.p.2"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening |
| 1484 | | process) rather than to a specific named resource at that server. For example, |
| | 1525 | <div id="message.routing"> |
| | 1526 | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#message.routing">Message Routing</a></h1> |
| | 1527 | <p id="rfc.section.4.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target |
| | 1528 | resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target. |
| 1524 | | </pre> <p>after connecting to port 8001 of host "www.example.org".</p> |
| 1525 | | <p id="rfc.section.4.1.p.15">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. |
| 1526 | | </p> |
| 1527 | | <p id="rfc.section.4.1.p.16">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, |
| 1528 | | except as noted above to replace a null path-absolute with "/" or "*". |
| 1529 | | </p> |
| 1530 | | <div class="note" id="rfc.section.4.1.p.17"> |
| 1531 | | <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using |
| 1532 | | a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been |
| 1533 | | known to rewrite the request-target. |
| 1534 | | </p> |
| | 1575 | </pre><p>after connecting to port 8001 of host "www.example.org".</p> |
| | 1576 | <p id="rfc.section.4.1.p.15">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. |
| | 1577 | </p> |
| | 1578 | <p id="rfc.section.4.1.p.16">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, |
| | 1579 | except as noted above to replace a null path-absolute with "/" or "*". |
| | 1580 | </p> |
| | 1581 | <div class="note" id="rfc.section.4.1.p.17"> |
| | 1582 | <p><b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using |
| | 1583 | a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been |
| | 1584 | known to rewrite the request-target. |
| | 1585 | </p> |
| | 1586 | </div> |
| | 1587 | </div> |
| | 1588 | <div id="the.resource.identified.by.a.request"> |
| | 1589 | <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> |
| | 1590 | <p id="rfc.section.4.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header |
| | 1591 | field. |
| | 1592 | </p> |
| | 1593 | <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix A.1.1</a> for other requirements on Host support in HTTP/1.1.) |
| | 1594 | </p> |
| | 1595 | <p id="rfc.section.4.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or |
| | 1596 | vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request: |
| | 1597 | </p> |
| | 1598 | <ol> |
| | 1599 | <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored. |
| | 1600 | </li> |
| | 1601 | <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the |
| | 1602 | Host header field value. |
| | 1603 | </li> |
| | 1604 | <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message. |
| | 1605 | </li> |
| | 1606 | </ol> |
| | 1607 | <p id="rfc.section.4.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host 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 determine |
| | 1608 | what exact resource is being requested. |
| | 1609 | </p> |
| | 1610 | </div> |
| | 1611 | <div id="effective.request.uri"> |
| | 1612 | <div id="rfc.iref.e.1"></div> |
| | 1613 | <div id="rfc.iref.t.4"></div> |
| | 1614 | <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a href="#effective.request.uri">Effective Request URI</a></h2> |
| | 1615 | <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><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>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection |
| | 1616 | context. The result of this process is called the "effective request URI". The "target resource" is the resource identified |
| | 1617 | by the effective request URI. |
| | 1618 | </p> |
| | 1619 | <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p> |
| | 1620 | <p id="rfc.section.4.3.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective |
| | 1621 | request URI is constructed by concatenating |
| | 1622 | </p> |
| | 1623 | <p id="rfc.section.4.3.p.4"></p> |
| | 1624 | <ul> |
| | 1625 | <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured |
| | 1626 | TCP connection, |
| | 1627 | </li> |
| | 1628 | <li>the octet sequence "://",</li> |
| | 1629 | <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8.3</a>), and |
| | 1630 | </li> |
| | 1631 | <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> |
| | 1632 | </ul> |
| | 1633 | <p id="rfc.section.4.3.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective |
| | 1634 | request URI is undefined. |
| | 1635 | </p> |
| | 1636 | <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> |
| | 1637 | <div id="rfc.figure.u.39"></div> |
| | 1638 | <p>Example 1: the effective request URI for the message</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 |
| | 1639 | Host: www.example.org:8080 |
| | 1640 | </pre><p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus |
| | 1641 | the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". |
| | 1642 | </p> |
| | 1643 | <div id="rfc.figure.u.40"></div> |
| | 1644 | <p>Example 2: the effective request URI for the message</p><pre class="text">OPTIONS * HTTP/1.1 |
| | 1645 | Host: www.example.org |
| | 1646 | </pre><p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org", |
| | 1647 | thus "https://www.example.org". |
| | 1648 | </p> |
| | 1649 | <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". |
| | 1650 | </p> |
| | 1651 | </div> |
| 1536 | | <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> |
| 1537 | | <p id="rfc.section.4.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header |
| 1538 | | field. |
| 1539 | | </p> |
| 1540 | | <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix A.1.1</a> for other requirements on Host support in HTTP/1.1.) |
| 1541 | | </p> |
| 1542 | | <p id="rfc.section.4.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or |
| 1543 | | vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request: |
| 1544 | | </p> |
| 1545 | | <ol> |
| 1546 | | <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored. |
| 1547 | | </li> |
| 1548 | | <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the |
| 1549 | | Host header field value. |
| 1550 | | </li> |
| 1551 | | <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message. |
| 1552 | | </li> |
| 1553 | | </ol> |
| 1554 | | <p id="rfc.section.4.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host 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 determine |
| 1555 | | what exact resource is being requested. |
| 1556 | | </p> |
| 1557 | | <div id="rfc.iref.e.1"></div> |
| 1558 | | <div id="rfc.iref.t.4"></div> |
| 1559 | | <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> |
| 1560 | | <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><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>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection |
| 1561 | | context. The result of this process is called the "effective request URI". The "target resource" is the resource identified |
| 1562 | | by the effective request URI. |
| 1563 | | </p> |
| 1564 | | <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p> |
| 1565 | | <p id="rfc.section.4.3.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective |
| 1566 | | request URI is constructed by concatenating |
| 1567 | | </p> |
| 1568 | | <p id="rfc.section.4.3.p.4"> </p> |
| 1569 | | <ul> |
| 1570 | | <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured |
| 1571 | | TCP connection, |
| 1572 | | </li> |
| 1573 | | <li>the octet sequence "://",</li> |
| 1574 | | <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8.3</a>), and |
| 1575 | | </li> |
| 1576 | | <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> |
| 1577 | | </ul> |
| 1578 | | <p id="rfc.section.4.3.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective |
| 1579 | | request URI is undefined. |
| 1580 | | </p> |
| 1581 | | <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> |
| 1582 | | <div id="rfc.figure.u.39"></div> |
| 1583 | | <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 |
| 1584 | | Host: www.example.org:8080 |
| 1585 | | </pre> <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus |
| 1586 | | the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". |
| 1587 | | </p> |
| 1588 | | <div id="rfc.figure.u.40"></div> |
| 1589 | | <p>Example 2: the effective request URI for the message</p> <pre class="text">OPTIONS * HTTP/1.1 |
| 1590 | | Host: www.example.org |
| 1591 | | </pre> <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org", |
| 1592 | | thus "https://www.example.org". |
| 1593 | | </p> |
| 1594 | | <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". |
| 1595 | | </p> |
| 1596 | | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> |
| 1597 | | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2> |
| 1598 | | <p id="rfc.section.5.1.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied |
| 1599 | | to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the |
| 1600 | | transfer-coding is a property of the message rather than a property of the representation that is being transferred. |
| 1601 | | </p> |
| 1602 | | <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> |
| | 1653 | <div id="protocol.parameters"> |
| | 1654 | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#protocol.parameters">Protocol Parameters</a></h1> |
| | 1655 | <div id="transfer.codings"> |
| | 1656 | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a href="#transfer.codings">Transfer Codings</a></h2> |
| | 1657 | <p id="rfc.section.5.1.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied |
| | 1658 | to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the |
| | 1659 | transfer-coding is a property of the message rather than a property of the representation that is being transferred. |
| | 1660 | </p> |
| | 1661 | <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> |
| 1688 | | </p> |
| 1689 | | <p id="rfc.section.5.1.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting |
| 1690 | | messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding |
| 1691 | | applied <em class="bcp14">MUST</em> be "chunked". If a 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. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. |
| 1692 | | </p> |
| 1693 | | <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h3> |
| 1694 | | <p id="rfc.section.5.1.2.p.1">The codings defined below can be used to compress the payload of a message.</p> |
| 1695 | | <div class="note" id="rfc.section.5.1.2.p.2"> |
| 1696 | | <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. |
| 1697 | | Their use here is representative of historical practice, not good design. |
| 1698 | | </p> |
| 1699 | | </div> |
| 1700 | | <div class="note" id="rfc.section.5.1.2.p.3"> |
| 1701 | | <p> <b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. |
| 1702 | | </p> |
| 1703 | | </div> |
| 1704 | | <div id="rfc.iref.c.8"></div> |
| 1705 | | <div id="rfc.iref.c.9"></div> |
| 1706 | | <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h4> |
| 1707 | | <p id="rfc.section.5.1.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch |
| 1708 | | coding (LZW). |
| 1709 | | </p> |
| 1710 | | <div id="rfc.iref.d.2"></div> |
| 1711 | | <div id="rfc.iref.c.10"></div> |
| 1712 | | <h4 id="rfc.section.5.1.2.2"><a href="#rfc.section.5.1.2.2">5.1.2.2</a> <a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4> |
| 1713 | | <p id="rfc.section.5.1.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>). |
| 1714 | | </p> |
| 1715 | | <div class="note" id="rfc.section.5.1.2.2.p.2"> |
| 1716 | | <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper. |
| 1717 | | </p> |
| 1718 | | </div> |
| 1719 | | <div id="rfc.iref.g.70"></div> |
| 1720 | | <div id="rfc.iref.c.11"></div> |
| 1721 | | <h4 id="rfc.section.5.1.2.3"><a href="#rfc.section.5.1.2.3">5.1.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4> |
| 1722 | | <p id="rfc.section.5.1.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. |
| 1723 | | </p> |
| 1724 | | <h3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3> |
| 1725 | | <p id="rfc.section.5.1.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p> |
| 1726 | | <p id="rfc.section.5.1.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: |
| 1727 | | </p> |
| 1728 | | <ul> |
| 1729 | | <li>Name</li> |
| 1730 | | <li>Description</li> |
| 1731 | | <li>Pointer to specification text</li> |
| 1732 | | </ul> |
| 1733 | | <p id="rfc.section.5.1.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 5.1.2</a>). |
| 1734 | | </p> |
| 1735 | | <p id="rfc.section.5.1.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. |
| 1736 | | </p> |
| 1737 | | <p id="rfc.section.5.1.3.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. |
| 1738 | | </p> |
| 1739 | | <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> |
| 1740 | | <p id="rfc.section.5.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields |
| 1741 | | using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. |
| 1742 | | By convention, the products are listed in order of their significance for identifying the application. |
| 1743 | | </p> |
| 1744 | | <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] |
| | 1748 | </p> |
| | 1749 | <p id="rfc.section.5.1.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting |
| | 1750 | messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding |
| | 1751 | applied <em class="bcp14">MUST</em> be "chunked". If a 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. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. |
| | 1752 | </p> |
| | 1753 | </div> |
| | 1754 | <div id="compression.codings"> |
| | 1755 | <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a href="#compression.codings">Compression Codings</a></h3> |
| | 1756 | <p id="rfc.section.5.1.2.p.1">The codings defined below can be used to compress the payload of a message.</p> |
| | 1757 | <div class="note" id="rfc.section.5.1.2.p.2"> |
| | 1758 | <p><b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. |
| | 1759 | Their use here is representative of historical practice, not good design. |
| | 1760 | </p> |
| | 1761 | </div> |
| | 1762 | <div class="note" id="rfc.section.5.1.2.p.3"> |
| | 1763 | <p><b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. |
| | 1764 | </p> |
| | 1765 | </div> |
| | 1766 | <div id="compress.coding"> |
| | 1767 | <div id="rfc.iref.c.8"></div> |
| | 1768 | <div id="rfc.iref.c.9"></div> |
| | 1769 | <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a href="#compress.coding">Compress Coding</a></h4> |
| | 1770 | <p id="rfc.section.5.1.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch |
| | 1771 | coding (LZW). |
| | 1772 | </p> |
| | 1773 | </div> |
| | 1774 | <div id="deflate.coding"> |
| | 1775 | <div id="rfc.iref.d.2"></div> |
| | 1776 | <div id="rfc.iref.c.10"></div> |
| | 1777 | <h4 id="rfc.section.5.1.2.2"><a href="#rfc.section.5.1.2.2">5.1.2.2</a> <a href="#deflate.coding">Deflate Coding</a></h4> |
| | 1778 | <p id="rfc.section.5.1.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>). |
| | 1779 | </p> |
| | 1780 | <div class="note" id="rfc.section.5.1.2.2.p.2"> |
| | 1781 | <p><b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper. |
| | 1782 | </p> |
| | 1783 | </div> |
| | 1784 | </div> |
| | 1785 | <div id="gzip.coding"> |
| | 1786 | <div id="rfc.iref.g.70"></div> |
| | 1787 | <div id="rfc.iref.c.11"></div> |
| | 1788 | <h4 id="rfc.section.5.1.2.3"><a href="#rfc.section.5.1.2.3">5.1.2.3</a> <a href="#gzip.coding">Gzip Coding</a></h4> |
| | 1789 | <p id="rfc.section.5.1.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. |
| | 1790 | </p> |
| | 1791 | </div> |
| | 1792 | </div> |
| | 1793 | <div id="transfer.coding.registry"> |
| | 1794 | <h3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3</a> <a href="#transfer.coding.registry">Transfer Coding Registry</a></h3> |
| | 1795 | <p id="rfc.section.5.1.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p> |
| | 1796 | <p id="rfc.section.5.1.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: |
| | 1797 | </p> |
| | 1798 | <ul> |
| | 1799 | <li>Name</li> |
| | 1800 | <li>Description</li> |
| | 1801 | <li>Pointer to specification text</li> |
| | 1802 | </ul> |
| | 1803 | <p id="rfc.section.5.1.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 5.1.2</a>). |
| | 1804 | </p> |
| | 1805 | <p id="rfc.section.5.1.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. |
| | 1806 | </p> |
| | 1807 | <p id="rfc.section.5.1.3.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. |
| | 1808 | </p> |
| | 1809 | </div> |
| | 1810 | </div> |
| | 1811 | <div id="product.tokens"> |
| | 1812 | <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a href="#product.tokens">Product Tokens</a></h2> |
| | 1813 | <p id="rfc.section.5.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields |
| | 1814 | using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. |
| | 1815 | By convention, the products are listed in order of their significance for identifying the application. |
| | 1816 | </p> |
| | 1817 | <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] |
| 1762 | | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connections" href="#connections">Connections</a></h1> |
| 1763 | | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> |
| 1764 | | <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> |
| 1765 | | <p id="rfc.section.6.1.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers |
| 1766 | | and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make |
| 1767 | | multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a |
| 1768 | | 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>. |
| 1769 | | </p> |
| 1770 | | <p id="rfc.section.6.1.1.p.2">Persistent HTTP connections have a number of advantages: </p> |
| 1771 | | <ul> |
| 1772 | | <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, |
| 1773 | | tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts. |
| 1774 | | </li> |
| 1775 | | <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without |
| 1776 | | waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. |
| 1777 | | </li> |
| 1778 | | <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to |
| 1779 | | determine the congestion state of the network. |
| 1780 | | </li> |
| 1781 | | <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li> |
| 1782 | | <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using |
| 1783 | | future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old |
| 1784 | | semantics after an error is reported. |
| 1785 | | </li> |
| 1786 | | </ul> |
| 1787 | | <p id="rfc.section.6.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. |
| 1788 | | </p> |
| 1789 | | <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3> |
| 1790 | | <p id="rfc.section.6.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior |
| 1791 | | 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. |
| 1792 | | </p> |
| 1793 | | <p id="rfc.section.6.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling |
| 1794 | | takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. |
| 1795 | | </p> |
| 1796 | | <h4 id="rfc.section.6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> |
| 1797 | | <p id="rfc.section.6.1.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 Connection header field including the connection-token |
| 1798 | | "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token "close". |
| 1799 | | </p> |
| 1800 | | <p id="rfc.section.6.1.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 |
| 1801 | | a Connection header field with the connection-token close. In case the client does not want to maintain a connection for more |
| 1802 | | than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token close. |
| 1803 | | </p> |
| 1804 | | <p id="rfc.section.6.1.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one |
| 1805 | | for the connection. |
| 1806 | | </p> |
| 1807 | | <p id="rfc.section.6.1.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. |
| 1808 | | </p> |
| 1809 | | <p id="rfc.section.6.1.2.1.p.5">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>. |
| 1810 | | </p> |
| 1811 | | <h4 id="rfc.section.6.1.2.2"><a href="#rfc.section.6.1.2.2">6.1.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> |
| 1812 | | <p id="rfc.section.6.1.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. |
| 1813 | | </p> |
| 1814 | | <p id="rfc.section.6.1.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. |
| 1815 | | </p> |
| 1816 | | <p id="rfc.section.6.1.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 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to |
| 1817 | | 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. |
| 1818 | | </p> |
| 1819 | | <h3 id="rfc.section.6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3> |
| 1820 | | <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 8.1</a>. |
| 1821 | | </p> |
| 1822 | | <p id="rfc.section.6.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects |
| 1823 | | to. Each persistent connection applies to only one transport link. |
| 1824 | | </p> |
| 1825 | | <p id="rfc.section.6.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). |
| 1826 | | </p> |
| 1827 | | <h4 id="rfc.section.6.1.3.1"><a href="#rfc.section.6.1.3.1">6.1.3.1</a> <a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4> |
| 1828 | | <p id="rfc.section.6.1.3.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> |
| 1829 | | <ul> |
| 1830 | | <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields |
| 1831 | | in responses MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry. |
| 1832 | | </li> |
| 1833 | | <li>Hop-by-hop header fields, which are meaningful only for a single transport-level connection, and are not stored by caches |
| 1834 | | or forwarded by proxies. |
| 1835 | | </li> |
| 1836 | | </ul> |
| 1837 | | <p id="rfc.section.6.1.3.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p> |
| 1838 | | <ul> |
| 1839 | | <li>Connection</li> |
| 1840 | | <li>Keep-Alive</li> |
| 1841 | | <li>Proxy-Authenticate</li> |
| 1842 | | <li>Proxy-Authorization</li> |
| 1843 | | <li>TE</li> |
| 1844 | | <li>Trailer</li> |
| 1845 | | <li>Transfer-Encoding</li> |
| 1846 | | <li>Upgrade</li> |
| 1847 | | </ul> |
| 1848 | | <p id="rfc.section.6.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> |
| 1849 | | <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a>). |
| 1850 | | </p> |
| 1851 | | <h4 id="rfc.section.6.1.3.2"><a href="#rfc.section.6.1.3.2">6.1.3.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4> |
| 1852 | | <p id="rfc.section.6.1.3.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 |
| 1853 | | 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. |
| 1854 | | </p> |
| 1855 | | <p id="rfc.section.6.1.3.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: |
| 1856 | | </p> |
| 1857 | | <ul> |
| 1858 | | <li>Allow</li> |
| 1859 | | <li>Content-Location</li> |
| 1860 | | <li>Content-MD5</li> |
| 1861 | | <li>ETag</li> |
| 1862 | | <li>Last-Modified</li> |
| 1863 | | <li>Server</li> |
| 1864 | | </ul> |
| 1865 | | <p id="rfc.section.6.1.3.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response: |
| 1866 | | </p> |
| 1867 | | <ul> |
| 1868 | | <li>Expires</li> |
| 1869 | | </ul> |
| 1870 | | <p id="rfc.section.6.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response. |
| 1871 | | </p> |
| 1872 | | <p id="rfc.section.6.1.3.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: |
| 1873 | | </p> |
| 1874 | | <ul> |
| 1875 | | <li>Content-Encoding</li> |
| 1876 | | <li>Content-Range</li> |
| 1877 | | <li>Content-Type</li> |
| 1878 | | </ul> |
| 1879 | | <p id="rfc.section.6.1.3.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 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| 1880 | | </p> |
| 1881 | | <div class="note" id="rfc.section.6.1.3.2.p.7"> |
| 1882 | | <p> <b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms |
| 1883 | | 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. |
| 1884 | | </p> |
| | 1839 | <div id="connections"> |
| | 1840 | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#connections">Connections</a></h1> |
| | 1841 | <div id="persistent.connections"> |
| | 1842 | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a href="#persistent.connections">Persistent Connections</a></h2> |
| | 1843 | <div id="persistent.purpose"> |
| | 1844 | <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a href="#persistent.purpose">Purpose</a></h3> |
| | 1845 | <p id="rfc.section.6.1.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers |
| | 1846 | and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make |
| | 1847 | multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a |
| | 1848 | 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>. |
| | 1849 | </p> |
| | 1850 | <p id="rfc.section.6.1.1.p.2">Persistent HTTP connections have a number of advantages: </p> |
| | 1851 | <ul> |
| | 1852 | <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, |
| | 1853 | tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts. |
| | 1854 | </li> |
| | 1855 | <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without |
| | 1856 | waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. |
| | 1857 | </li> |
| | 1858 | <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to |
| | 1859 | determine the congestion state of the network. |
| | 1860 | </li> |
| | 1861 | <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li> |
| | 1862 | <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using |
| | 1863 | future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old |
| | 1864 | semantics after an error is reported. |
| | 1865 | </li> |
| | 1866 | </ul> |
| | 1867 | <p id="rfc.section.6.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. |
| | 1868 | </p> |
| | 1869 | </div> |
| | 1870 | <div id="persistent.overall"> |
| | 1871 | <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> <a href="#persistent.overall">Overall Operation</a></h3> |
| | 1872 | <p id="rfc.section.6.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior |
| | 1873 | 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. |
| | 1874 | </p> |
| | 1875 | <p id="rfc.section.6.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling |
| | 1876 | takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. |
| | 1877 | </p> |
| | 1878 | <div id="persistent.negotiation"> |
| | 1879 | <h4 id="rfc.section.6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a> <a href="#persistent.negotiation">Negotiation</a></h4> |
| | 1880 | <p id="rfc.section.6.1.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 Connection header field including the connection-token |
| | 1881 | "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token "close". |
| | 1882 | </p> |
| | 1883 | <p id="rfc.section.6.1.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 |
| | 1884 | a Connection header field with the connection-token close. In case the client does not want to maintain a connection for more |
| | 1885 | than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token close. |
| | 1886 | </p> |
| | 1887 | <p id="rfc.section.6.1.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one |
| | 1888 | for the connection. |
| | 1889 | </p> |
| | 1890 | <p id="rfc.section.6.1.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. |
| | 1891 | </p> |
| | 1892 | <p id="rfc.section.6.1.2.1.p.5">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>. |
| | 1893 | </p> |
| | 1894 | </div> |
| | 1895 | <div id="pipelining"> |
| | 1896 | <h4 id="rfc.section.6.1.2.2"><a href="#rfc.section.6.1.2.2">6.1.2.2</a> <a href="#pipelining">Pipelining</a></h4> |
| | 1897 | <p id="rfc.section.6.1.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. |
| | 1898 | </p> |
| | 1899 | <p id="rfc.section.6.1.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. |
| | 1900 | </p> |
| | 1901 | <p id="rfc.section.6.1.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 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to |
| | 1902 | 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. |
| | 1903 | </p> |
| | 1904 | </div> |
| | 1905 | </div> |
| | 1906 | <div id="persistent.proxy"> |
| | 1907 | <h3 id="rfc.section.6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a> <a href="#persistent.proxy">Proxy Servers</a></h3> |
| | 1908 | <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 8.1</a>. |
| | 1909 | </p> |
| | 1910 | <p id="rfc.section.6.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects |
| | 1911 | to. Each persistent connection applies to only one transport link. |
| | 1912 | </p> |
| | 1913 | <p id="rfc.section.6.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="https://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). |
| | 1914 | </p> |
| | 1915 | <div id="end-to-end.and.hop-by-hop.header-fields"> |
| | 1916 | <h4 id="rfc.section.6.1.3.1"><a href="#rfc.section.6.1.3.1">6.1.3.1</a> <a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4> |
| | 1917 | <p id="rfc.section.6.1.3.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> |
| | 1918 | <ul> |
| | 1919 | <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields |
| | 1920 | in responses MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry. |
| | 1921 | </li> |
| | 1922 | <li>Hop-by-hop header fields, which are meaningful only for a single transport-level connection, and are not stored by caches |
| | 1923 | or forwarded by proxies. |
| | 1924 | </li> |
| | 1925 | </ul> |
| | 1926 | <p id="rfc.section.6.1.3.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p> |
| | 1927 | <ul> |
| | 1928 | <li>Connection</li> |
| | 1929 | <li>Keep-Alive</li> |
| | 1930 | <li>Proxy-Authenticate</li> |
| | 1931 | <li>Proxy-Authorization</li> |
| | 1932 | <li>TE</li> |
| | 1933 | <li>Trailer</li> |
| | 1934 | <li>Transfer-Encoding</li> |
| | 1935 | <li>Upgrade</li> |
| | 1936 | </ul> |
| | 1937 | <p id="rfc.section.6.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> |
| | 1938 | <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a>). |
| | 1939 | </p> |
| | 1940 | </div> |
| | 1941 | <div id="non-modifiable.header-fields"> |
| | 1942 | <h4 id="rfc.section.6.1.3.2"><a href="#rfc.section.6.1.3.2">6.1.3.2</a> <a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4> |
| | 1943 | <p id="rfc.section.6.1.3.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 |
| | 1944 | 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. |
| | 1945 | </p> |
| | 1946 | <p id="rfc.section.6.1.3.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: |
| | 1947 | </p> |
| | 1948 | <ul> |
| | 1949 | <li>Allow</li> |
| | 1950 | <li>Content-Location</li> |
| | 1951 | <li>Content-MD5</li> |
| | 1952 | <li>ETag</li> |
| | 1953 | <li>Last-Modified</li> |
| | 1954 | <li>Server</li> |
| | 1955 | </ul> |
| | 1956 | <p id="rfc.section.6.1.3.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response: |
| | 1957 | </p> |
| | 1958 | <ul> |
| | 1959 | <li>Expires</li> |
| | 1960 | </ul> |
| | 1961 | <p id="rfc.section.6.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response. |
| | 1962 | </p> |
| | 1963 | <p id="rfc.section.6.1.3.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: |
| | 1964 | </p> |
| | 1965 | <ul> |
| | 1966 | <li>Content-Encoding</li> |
| | 1967 | <li>Content-Range</li> |
| | 1968 | <li>Content-Type</li> |
| | 1969 | </ul> |
| | 1970 | <p id="rfc.section.6.1.3.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 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| | 1971 | </p> |
| | 1972 | <div class="note" id="rfc.section.6.1.3.2.p.7"> |
| | 1973 | <p><b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms |
| | 1974 | 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. |
| | 1975 | </p> |
| | 1976 | </div> |
| | 1977 | <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</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 5.1</a>). |
| | 1978 | </p> |
| | 1979 | </div> |
| | 1980 | </div> |
| | 1981 | <div id="persistent.practical"> |
| | 1982 | <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a> <a href="#persistent.practical">Practical Considerations</a></h3> |
| | 1983 | <p id="rfc.section.6.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers |
| | 1984 | might make this a higher value since it is likely that the client will be making more connections through the same server. |
| | 1985 | The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client |
| | 1986 | or the server. |
| | 1987 | </p> |
| | 1988 | <p id="rfc.section.6.1.4.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 |
| | 1989 | not detect the other side's close promptly it could cause unnecessary resource drain on the network. |
| | 1990 | </p> |
| | 1991 | <p id="rfc.section.6.1.4.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 |
| | 1992 | that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed |
| | 1993 | while it was idle, but from the client's point of view, a request is in progress. |
| | 1994 | </p> |
| | 1995 | <p id="rfc.section.6.1.4.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). |
| | 1996 | </p> |
| | 1997 | <p id="rfc.section.6.1.4.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many |
| | 1998 | applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages |
| | 1999 | clients to be conservative when opening multiple connections. |
| | 2000 | </p> |
| | 2001 | <p id="rfc.section.6.1.4.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant |
| | 2002 | server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used |
| | 2003 | consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side |
| | 2004 | effects in congested networks. |
| | 2005 | </p> |
| | 2006 | <p id="rfc.section.6.1.4.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> |
| | 2007 | </div> |
| | 2008 | <div id="persistent.retrying.requests"> |
| | 2009 | <h3 id="rfc.section.6.1.5"><a href="#rfc.section.6.1.5">6.1.5</a> <a href="#persistent.retrying.requests">Retrying Requests</a></h3> |
| | 2010 | <p id="rfc.section.6.1.5.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 |
| | 2011 | sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[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 |
| | 2012 | 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. |
| | 2013 | </p> |
| | 2014 | </div> |
| | 2015 | </div> |
| | 2016 | <div id="message.transmission.requirements"> |
| | 2017 | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a href="#message.transmission.requirements">Message Transmission Requirements</a></h2> |
| | 2018 | <div id="persistent.flow"> |
| | 2019 | <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a href="#persistent.flow">Persistent Connections and Flow Control</a></h3> |
| | 2020 | <p id="rfc.section.6.2.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 |
| | 2021 | connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. |
| | 2022 | </p> |
| | 2023 | </div> |
| | 2024 | <div id="persistent.monitor"> |
| | 2025 | <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> |
| | 2026 | <p id="rfc.section.6.2.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 |
| | 2027 | 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 5.1</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. |
| | 2028 | </p> |
| | 2029 | </div> |
| | 2030 | <div id="use.of.the.100.status"> |
| | 2031 | <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> |
| | 2032 | <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[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 |
| | 2033 | to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might |
| | 2034 | either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without |
| | 2035 | looking at the body. |
| | 2036 | </p> |
| | 2037 | <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p> |
| | 2038 | <ul> |
| | 2039 | <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. |
| | 2040 | </li> |
| | 2041 | <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. |
| | 2042 | </li> |
| | 2043 | </ul> |
| | 2044 | <p id="rfc.section.6.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: |
| | 2045 | 100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client |
| | 2046 | sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code, |
| | 2047 | the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. |
| | 2048 | </p> |
| | 2049 | <p id="rfc.section.6.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p> |
| | 2050 | <ul> |
| | 2051 | <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status |
| | 2052 | code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) 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. |
| | 2053 | </li> |
| | 2054 | <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect header field with the "100-continue" expectation, |
| | 2055 | and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this |
| | 2056 | rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field |
| | 2057 | with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated |
| | 2058 | with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other |
| | 2059 | HTTP-version value. |
| | 2060 | </li> |
| | 2061 | <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request. |
| | 2062 | </li> |
| | 2063 | <li>An origin server that sends a 100 (Continue) 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 |
| | 2064 | prematurely. |
| | 2065 | </li> |
| | 2066 | <li>If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the |
| | 2067 | request includes a request body, and the server responds with a final status code before reading the entire request body from |
| | 2068 | 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, |
| | 2069 | the client might not reliably receive the response message. However, this requirement is not be construed as preventing a |
| | 2070 | server from defending itself against denial-of-service attacks, or from badly broken client implementations. |
| | 2071 | </li> |
| | 2072 | </ul> |
| | 2073 | <p id="rfc.section.6.2.3.p.5">Requirements for HTTP/1.1 proxies: </p> |
| | 2074 | <ul> |
| | 2075 | <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either |
| | 2076 | knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server, |
| | 2077 | it <em class="bcp14">MUST</em> forward the request, including the Expect header field. |
| | 2078 | </li> |
| | 2079 | <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 417 (Expectation Failed) status code. |
| | 2080 | </li> |
| | 2081 | <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. |
| | 2082 | </li> |
| | 2083 | <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include |
| | 2084 | an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of |
| | 2085 | 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). |
| | 2086 | </li> |
| | 2087 | </ul> |
| | 2088 | </div> |
| | 2089 | </div> |
| 1886 | | <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</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 5.1</a>). |
| 1887 | | </p> |
| 1888 | | <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> |
| 1889 | | <p id="rfc.section.6.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers |
| 1890 | | might make this a higher value since it is likely that the client will be making more connections through the same server. |
| 1891 | | The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client |
| 1892 | | or the server. |
| 1893 | | </p> |
| 1894 | | <p id="rfc.section.6.1.4.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 |
| 1895 | | not detect the other side's close promptly it could cause unnecessary resource drain on the network. |
| 1896 | | </p> |
| 1897 | | <p id="rfc.section.6.1.4.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 |
| 1898 | | that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed |
| 1899 | | while it was idle, but from the client's point of view, a request is in progress. |
| 1900 | | </p> |
| 1901 | | <p id="rfc.section.6.1.4.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). |
| 1902 | | </p> |
| 1903 | | <p id="rfc.section.6.1.4.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many |
| 1904 | | applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages |
| 1905 | | clients to be conservative when opening multiple connections. |
| 1906 | | </p> |
| 1907 | | <p id="rfc.section.6.1.4.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant |
| 1908 | | server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used |
| 1909 | | consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side |
| 1910 | | effects in congested networks. |
| 1911 | | </p> |
| 1912 | | <p id="rfc.section.6.1.4.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> |
| 1913 | | <h3 id="rfc.section.6.1.5"><a href="#rfc.section.6.1.5">6.1.5</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> |
| 1914 | | <p id="rfc.section.6.1.5.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 |
| 1915 | | sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[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 |
| 1916 | | 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. |
| 1917 | | </p> |
| 1918 | | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2> |
| 1919 | | <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3> |
| 1920 | | <p id="rfc.section.6.2.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 |
| 1921 | | connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. |
| 1922 | | </p> |
| 1923 | | <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> |
| 1924 | | <p id="rfc.section.6.2.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 |
| 1925 | | 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 5.1</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. |
| 1926 | | </p> |
| 1927 | | <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> |
| 1928 | | <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[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 |
| 1929 | | to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might |
| 1930 | | either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without |
| 1931 | | looking at the body. |
| 1932 | | </p> |
| 1933 | | <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p> |
| 1934 | | <ul> |
| 1935 | | <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. |
| 1936 | | </li> |
| 1937 | | <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. |
| 1938 | | </li> |
| 1939 | | </ul> |
| 1940 | | <p id="rfc.section.6.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: |
| 1941 | | 100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client |
| 1942 | | sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code, |
| 1943 | | the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. |
| 1944 | | </p> |
| 1945 | | <p id="rfc.section.6.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p> |
| 1946 | | <ul> |
| 1947 | | <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status |
| 1948 | | code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) 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. |
| 1949 | | </li> |
| 1950 | | <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect header field with the "100-continue" expectation, |
| 1951 | | and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this |
| 1952 | | rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field |
| 1953 | | with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated |
| 1954 | | with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other |
| 1955 | | HTTP-version value. |
| 1956 | | </li> |
| 1957 | | <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request. |
| 1958 | | </li> |
| 1959 | | <li>An origin server that sends a 100 (Continue) 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 |
| 1960 | | prematurely. |
| 1961 | | </li> |
| 1962 | | <li>If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the |
| 1963 | | request includes a request body, and the server responds with a final status code before reading the entire request body from |
| 1964 | | 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, |
| 1965 | | the client might not reliably receive the response message. However, this requirement is not be construed as preventing a |
| 1966 | | server from defending itself against denial-of-service attacks, or from badly broken client implementations. |
| 1967 | | </li> |
| 1968 | | </ul> |
| 1969 | | <p id="rfc.section.6.2.3.p.5">Requirements for HTTP/1.1 proxies: </p> |
| 1970 | | <ul> |
| 1971 | | <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either |
| 1972 | | knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server, |
| 1973 | | it <em class="bcp14">MUST</em> forward the request, including the Expect header field. |
| 1974 | | </li> |
| 1975 | | <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 417 (Expectation Failed) status code. |
| 1976 | | </li> |
| 1977 | | <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. |
| 1978 | | </li> |
| 1979 | | <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include |
| 1980 | | an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of |
| 1981 | | 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). |
| 1982 | | </li> |
| 1983 | | </ul> |
| 1984 | | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="misc" href="#misc">Miscellaneous notes that might disappear</a></h1> |
| 1985 | | <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h2> |
| 1986 | | <p id="rfc.section.7.1.p.1"> <span class="comment" id="TBD-aliases-harmful">[<a href="#TBD-aliases-harmful" class="smpl">TBD-aliases-harmful</a>: describe why aliases like webcal are harmful.]</span> |
| 1987 | | </p> |
| 1988 | | <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="http.proxy" href="#http.proxy">Use of HTTP for proxy communication</a></h2> |
| 1989 | | <p id="rfc.section.7.2.p.1"> <span class="comment" id="TBD-proxy-other">[<a href="#TBD-proxy-other" class="smpl">TBD-proxy-other</a>: Configured to use HTTP to proxy HTTP or other protocols.]</span> |
| 1990 | | </p> |
| 1991 | | <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="http.intercept" href="#http.intercept">Interception of HTTP for access control</a></h2> |
| 1992 | | <p id="rfc.section.7.3.p.1"> <span class="comment" id="TBD-intercept">[<a href="#TBD-intercept" class="smpl">TBD-intercept</a>: Interception of HTTP traffic for initiating access control.]</span> |
| 1993 | | </p> |
| 1994 | | <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="http.others" href="#http.others">Use of HTTP by other protocols</a></h2> |
| 1995 | | <p id="rfc.section.7.4.p.1"> <span class="comment" id="TBD-profiles">[<a href="#TBD-profiles" class="smpl">TBD-profiles</a>: Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.]</span> |
| 1996 | | </p> |
| 1997 | | <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="http.media" href="#http.media">Use of HTTP by media type specification</a></h2> |
| 1998 | | <p id="rfc.section.7.5.p.1"> <span class="comment" id="TBD-hypertext">[<a href="#TBD-hypertext" class="smpl">TBD-hypertext</a>: Instructions on composing HTTP requests via hypertext formats.]</span> |
| 1999 | | </p> |
| 2000 | | <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> |
| 2001 | | <p id="rfc.section.8.p.1">This section defines the syntax and semantics of HTTP header fields related to message origination, framing, and routing.</p> |
| 2002 | | <div id="rfc.table.u.1"> |
| 2003 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| 2004 | | <thead> |
| 2005 | | <tr> |
| 2006 | | <th>Header Field Name</th> |
| 2007 | | <th>Defined in...</th> |
| 2008 | | </tr> |
| 2009 | | </thead> |
| 2010 | | <tbody> |
| 2011 | | <tr> |
| 2012 | | <td class="left">Connection</td> |
| 2013 | | <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 8.1</a></td> |
| 2014 | | </tr> |
| 2015 | | <tr> |
| 2016 | | <td class="left">Content-Length</td> |
| 2017 | | <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 8.2</a></td> |
| 2018 | | </tr> |
| 2019 | | <tr> |
| 2020 | | <td class="left">Host</td> |
| 2021 | | <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8.3</a></td> |
| 2022 | | </tr> |
| 2023 | | <tr> |
| 2024 | | <td class="left">TE</td> |
| 2025 | | <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 8.4</a></td> |
| 2026 | | </tr> |
| 2027 | | <tr> |
| 2028 | | <td class="left">Trailer</td> |
| 2029 | | <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.5</a></td> |
| 2030 | | </tr> |
| 2031 | | <tr> |
| 2032 | | <td class="left">Transfer-Encoding</td> |
| 2033 | | <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.6</a></td> |
| 2034 | | </tr> |
| 2035 | | <tr> |
| 2036 | | <td class="left">Upgrade</td> |
| 2037 | | <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.7</a></td> |
| 2038 | | </tr> |
| 2039 | | <tr> |
| 2040 | | <td class="left">Via</td> |
| 2041 | | <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8.8</a></td> |
| 2042 | | </tr> |
| 2043 | | </tbody> |
| 2044 | | </table> |
| | 2091 | <div id="misc"> |
| | 2092 | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#misc">Miscellaneous notes that might disappear</a></h1> |
| | 2093 | <div id="scheme.aliases"> |
| | 2094 | <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a href="#scheme.aliases">Scheme aliases considered harmful</a></h2> |
| | 2095 | <p id="rfc.section.7.1.p.1"><span class="comment" id="TBD-aliases-harmful">[<a href="#TBD-aliases-harmful" class="smpl">TBD-aliases-harmful</a>: describe why aliases like webcal are harmful.]</span> |
| | 2096 | </p> |
| | 2097 | </div> |
| | 2098 | <div id="http.proxy"> |
| | 2099 | <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a href="#http.proxy">Use of HTTP for proxy communication</a></h2> |
| | 2100 | <p id="rfc.section.7.2.p.1"><span class="comment" id="TBD-proxy-other">[<a href="#TBD-proxy-other" class="smpl">TBD-proxy-other</a>: Configured to use HTTP to proxy HTTP or other protocols.]</span> |
| | 2101 | </p> |
| | 2102 | </div> |
| | 2103 | <div id="http.intercept"> |
| | 2104 | <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a href="#http.intercept">Interception of HTTP for access control</a></h2> |
| | 2105 | <p id="rfc.section.7.3.p.1"><span class="comment" id="TBD-intercept">[<a href="#TBD-intercept" class="smpl">TBD-intercept</a>: Interception of HTTP traffic for initiating access control.]</span> |
| | 2106 | </p> |
| | 2107 | </div> |
| | 2108 | <div id="http.others"> |
| | 2109 | <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a href="#http.others">Use of HTTP by other protocols</a></h2> |
| | 2110 | <p id="rfc.section.7.4.p.1"><span class="comment" id="TBD-profiles">[<a href="#TBD-profiles" class="smpl">TBD-profiles</a>: Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.]</span> |
| | 2111 | </p> |
| | 2112 | </div> |
| | 2113 | <div id="http.media"> |
| | 2114 | <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a href="#http.media">Use of HTTP by media type specification</a></h2> |
| | 2115 | <p id="rfc.section.7.5.p.1"><span class="comment" id="TBD-hypertext">[<a href="#TBD-hypertext" class="smpl">TBD-hypertext</a>: Instructions on composing HTTP requests via hypertext formats.]</span> |
| | 2116 | </p> |
| | 2117 | </div> |
| 2227 | | protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP |
| 2228 | | with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult |
| 2229 | | transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol |
| 2230 | | while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by |
| 2231 | | the server, possibly according to the nature of the request method or target resource). |
| 2232 | | </p> |
| 2233 | | <p id="rfc.section.8.7.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. |
| 2234 | | Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities |
| 2235 | | and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, |
| 2236 | | 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. |
| 2237 | | </p> |
| 2238 | | <p id="rfc.section.8.7.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message. |
| 2239 | | </p> |
| 2240 | | <p id="rfc.section.8.7.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it |
| 2241 | | is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). |
| 2242 | | </p> |
| 2243 | | <p id="rfc.section.8.7.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched |
| 2244 | | to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) 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. |
| 2245 | | </p> |
| 2246 | | <p id="rfc.section.8.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined |
| 2247 | | by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined |
| 2248 | | below. |
| 2249 | | </p> |
| 2250 | | <h3 id="rfc.section.8.7.1"><a href="#rfc.section.8.7.1">8.7.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3> |
| 2251 | | <p id="rfc.section.8.7.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header |
| 2252 | | field. Each registered token is associated with contact information and an optional set of specifications that details how |
| 2253 | | the connection will be processed after it has been upgraded. |
| 2254 | | </p> |
| 2255 | | <p id="rfc.section.8.7.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules: |
| 2256 | | </p> |
| 2257 | | <ol> |
| 2258 | | <li>A token, once registered, stays registered forever.</li> |
| 2259 | | <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration. |
| 2260 | | </li> |
| 2261 | | <li>The registration <em class="bcp14">MUST</em> name a point of contact. |
| 2262 | | </li> |
| 2263 | | <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available. |
| 2264 | | </li> |
| 2265 | | <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. |
| 2266 | | </li> |
| 2267 | | <li>The responsible party for the first registration of a "product" token <em class="bcp14">MUST</em> approve later registrations of a "version" token together with that "product" token before they can be registered. |
| 2268 | | </li> |
| 2269 | | <li>If absolutely required, the IESG <em class="bcp14">MAY</em> reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted. |
| 2270 | | </li> |
| 2271 | | </ol> |
| 2272 | | <div id="rfc.iref.v.1"></div> |
| 2273 | | <div id="rfc.iref.h.14"></div> |
| 2274 | | <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="header.via" href="#header.via">Via</a></h2> |
| 2275 | | <p id="rfc.section.8.8.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server |
| 2276 | | on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email |
| 2277 | | systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities |
| 2278 | | of all senders along the request/response chain. |
| 2279 | | </p> |
| 2280 | | <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> |
| | 2360 | protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP |
| | 2361 | with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult |
| | 2362 | transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol |
| | 2363 | while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by |
| | 2364 | the server, possibly according to the nature of the request method or target resource). |
| | 2365 | </p> |
| | 2366 | <p id="rfc.section.8.7.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. |
| | 2367 | Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities |
| | 2368 | and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, |
| | 2369 | 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. |
| | 2370 | </p> |
| | 2371 | <p id="rfc.section.8.7.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message. |
| | 2372 | </p> |
| | 2373 | <p id="rfc.section.8.7.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it |
| | 2374 | is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). |
| | 2375 | </p> |
| | 2376 | <p id="rfc.section.8.7.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched |
| | 2377 | to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) 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. |
| | 2378 | </p> |
| | 2379 | <p id="rfc.section.8.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined |
| | 2380 | by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined |
| | 2381 | below. |
| | 2382 | </p> |
| | 2383 | <div id="upgrade.token.registry"> |
| | 2384 | <h3 id="rfc.section.8.7.1"><a href="#rfc.section.8.7.1">8.7.1</a> <a href="#upgrade.token.registry">Upgrade Token Registry</a></h3> |
| | 2385 | <p id="rfc.section.8.7.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header |
| | 2386 | field. Each registered token is associated with contact information and an optional set of specifications that details how |
| | 2387 | the connection will be processed after it has been upgraded. |
| | 2388 | </p> |
| | 2389 | <p id="rfc.section.8.7.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules: |
| | 2390 | </p> |
| | 2391 | <ol> |
| | 2392 | <li>A token, once registered, stays registered forever.</li> |
| | 2393 | <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration. |
| | 2394 | </li> |
| | 2395 | <li>The registration <em class="bcp14">MUST</em> name a point of contact. |
| | 2396 | </li> |
| | 2397 | <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available. |
| | 2398 | </li> |
| | 2399 | <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. |
| | 2400 | </li> |
| | 2401 | <li>The responsible party for the first registration of a "product" token <em class="bcp14">MUST</em> approve later registrations of a "version" token together with that "product" token before they can be registered. |
| | 2402 | </li> |
| | 2403 | <li>If absolutely required, the IESG <em class="bcp14">MAY</em> reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted. |
| | 2404 | </li> |
| | 2405 | </ol> |
| | 2406 | </div> |
| | 2407 | </div> |
| | 2408 | <div id="header.via"> |
| | 2409 | <div id="rfc.iref.v.1"></div> |
| | 2410 | <div id="rfc.iref.h.14"></div> |
| | 2411 | <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a href="#header.via">Via</a></h2> |
| | 2412 | <p id="rfc.section.8.8.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server |
| | 2413 | on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email |
| | 2414 | systems (<a href="https://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities |
| | 2415 | of all senders along the request/response chain. |
| | 2416 | </p> |
| | 2417 | <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> |
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)