| 714 | | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> |
| 715 | | <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and |
| 716 | | self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document |
| 717 | | is the first in a series of documents that collectively form the HTTP/1.1 specification: |
| 718 | | </p> |
| 719 | | <ul class="empty"> |
| 720 | | <li>RFC xxx1: Message Syntax and Routing</li> |
| 721 | | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" id="rfc.xref.Part2.1">RFC xxx2</cite>: Semantics and Content |
| 722 | | </li> |
| 723 | | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" id="rfc.xref.Part4.1">RFC xxx3</cite>: Conditional Requests |
| 724 | | </li> |
| 725 | | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests" id="rfc.xref.Part5.1">RFC xxx4</cite>: Range Requests |
| 726 | | </li> |
| 727 | | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching" id="rfc.xref.Part6.1">RFC xxx5</cite>: Caching |
| 728 | | </li> |
| 729 | | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication" id="rfc.xref.Part7.1">RFC xxx6</cite>: Authentication |
| 730 | | </li> |
| 731 | | </ul> |
| 732 | | <p id="rfc.section.1.p.2">This HTTP/1.1 specification obsoletes and moves to historic status <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite>, its predecessor <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.1">RFC 2068</cite>, and <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning). This specification also updates the use of CONNECT to establish a tunnel, previously defined in <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">RFC 2817</cite>, and defines the "https" URI scheme that was described informally in <cite title="HTTP Over TLS" id="rfc.xref.RFC2818.1">RFC 2818</cite>. |
| 733 | | </p> |
| 734 | | <p id="rfc.section.1.p.3">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented |
| 735 | | by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do |
| 736 | | not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated |
| 737 | | with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used |
| 738 | | effectively in many different contexts and for which implementations can evolve independently over time. |
| 739 | | </p> |
| 740 | | <p id="rfc.section.1.p.4">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information |
| 741 | | systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols |
| 742 | | into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. |
| 743 | | </p> |
| 744 | | <p id="rfc.section.1.p.5">One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, |
| 745 | | we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of |
| 746 | | recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding |
| 747 | | changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps |
| 748 | | at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. |
| 749 | | </p> |
| 750 | | <p id="rfc.section.1.p.6">This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI |
| 751 | | schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. |
| 752 | | Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, |
| 753 | | thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. |
| 754 | | </p> |
| 755 | | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirement Notation</a></h2> |
| 756 | | <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" |
| 757 | | 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>. |
| 758 | | </p> |
| 759 | | <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>. |
| 760 | | </p> |
| 761 | | <div id="rfc.iref.g.1"></div> |
| 762 | | <div id="rfc.iref.g.2"></div> |
| 763 | | <div id="rfc.iref.g.3"></div> |
| 764 | | <div id="rfc.iref.g.4"></div> |
| 765 | | <div id="rfc.iref.g.5"></div> |
| 766 | | <div id="rfc.iref.g.6"></div> |
| 767 | | <div id="rfc.iref.g.7"></div> |
| 768 | | <div id="rfc.iref.g.8"></div> |
| 769 | | <div id="rfc.iref.g.9"></div> |
| 770 | | <div id="rfc.iref.g.10"></div> |
| 771 | | <div id="rfc.iref.g.11"></div> |
| 772 | | <div id="rfc.iref.g.12"></div> |
| 773 | | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> |
| 774 | | <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="#abnf.extension" title="ABNF list extension: #rule">Section 7</a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. |
| 775 | | </p> |
| 776 | | <div id="core.rules"> |
| 777 | | <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 |
| 778 | | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
| 779 | | (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). |
| | 717 | <div id="introduction"> |
| | 718 | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a></h1> |
| | 719 | <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and |
| | 720 | self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document |
| | 721 | is the first in a series of documents that collectively form the HTTP/1.1 specification: |
| | 723 | <ul class="empty"> |
| | 724 | <li>RFC xxx1: Message Syntax and Routing</li> |
| | 725 | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" id="rfc.xref.Part2.1">RFC xxx2</cite>: Semantics and Content |
| | 726 | </li> |
| | 727 | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" id="rfc.xref.Part4.1">RFC xxx3</cite>: Conditional Requests |
| | 728 | </li> |
| | 729 | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests" id="rfc.xref.Part5.1">RFC xxx4</cite>: Range Requests |
| | 730 | </li> |
| | 731 | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching" id="rfc.xref.Part6.1">RFC xxx5</cite>: Caching |
| | 732 | </li> |
| | 733 | <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication" id="rfc.xref.Part7.1">RFC xxx6</cite>: Authentication |
| | 734 | </li> |
| | 735 | </ul> |
| | 736 | <p id="rfc.section.1.p.2">This HTTP/1.1 specification obsoletes and moves to historic status <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite>, its predecessor <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.1">RFC 2068</cite>, and <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning). This specification also updates the use of CONNECT to establish a tunnel, previously defined in <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">RFC 2817</cite>, and defines the "https" URI scheme that was described informally in <cite title="HTTP Over TLS" id="rfc.xref.RFC2818.1">RFC 2818</cite>. |
| | 737 | </p> |
| | 738 | <p id="rfc.section.1.p.3">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented |
| | 739 | by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do |
| | 740 | not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated |
| | 741 | with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used |
| | 742 | effectively in many different contexts and for which implementations can evolve independently over time. |
| | 743 | </p> |
| | 744 | <p id="rfc.section.1.p.4">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information |
| | 745 | systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols |
| | 746 | into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. |
| | 747 | </p> |
| | 748 | <p id="rfc.section.1.p.5">One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, |
| | 749 | we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of |
| | 750 | recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding |
| | 751 | changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps |
| | 752 | at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. |
| | 753 | </p> |
| | 754 | <p id="rfc.section.1.p.6">This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI |
| | 755 | schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. |
| | 756 | Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, |
| | 757 | thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. |
| | 758 | </p> |
| | 759 | <div id="intro.requirements"> |
| | 760 | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a href="#intro.requirements">Requirement Notation</a></h2> |
| | 761 | <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" |
| | 762 | 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>. |
| | 763 | </p> |
| | 764 | <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>. |
| | 765 | </p> |
| | 766 | </div> |
| | 767 | <div id="notation"> |
| | 768 | <div id="rfc.iref.g.1"></div> |
| | 769 | <div id="rfc.iref.g.2"></div> |
| | 770 | <div id="rfc.iref.g.3"></div> |
| | 771 | <div id="rfc.iref.g.4"></div> |
| | 772 | <div id="rfc.iref.g.5"></div> |
| | 773 | <div id="rfc.iref.g.6"></div> |
| | 774 | <div id="rfc.iref.g.7"></div> |
| | 775 | <div id="rfc.iref.g.8"></div> |
| | 776 | <div id="rfc.iref.g.9"></div> |
| | 777 | <div id="rfc.iref.g.10"></div> |
| | 778 | <div id="rfc.iref.g.11"></div> |
| | 779 | <div id="rfc.iref.g.12"></div> |
| | 780 | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a href="#notation">Syntax Notation</a></h2> |
| | 781 | <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="#abnf.extension" title="ABNF list extension: #rule">Section 7</a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. |
| | 782 | </p> |
| | 783 | <div id="core.rules"> |
| | 784 | <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 |
| | 785 | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
| | 786 | (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). |
| | 787 | </p> |
| | 788 | </div> |
| | 789 | <p id="rfc.section.1.2.p.3">As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.</p> |
| | 790 | </div> |
| 842 | | </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="implementation-diversity" href="#implementation-diversity">Implementation Diversity</a></h2> |
| 843 | | <p id="rfc.section.2.2.p.1">When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers |
| 844 | | and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household |
| 845 | | appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude |
| 846 | | of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components, |
| 847 | | office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms. |
| 848 | | </p> |
| 849 | | <p id="rfc.section.2.2.p.2">The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of |
| 850 | | a request. In many cases, a user agent is installed or configured to run in the background and save its results for later |
| 851 | | inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically |
| 852 | | given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph. |
| 853 | | </p> |
| 854 | | <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that we cannot assume the user agent can make interactive suggestions to a user |
| 855 | | or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting |
| 856 | | of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, |
| 857 | | requirements that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, |
| 858 | | run-time options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption |
| 859 | | of normal processing if the user has already made that choice. |
| 860 | | </p> |
| 861 | | <div id="rfc.iref.i.1"></div> |
| 862 | | <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> |
| 863 | | <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of |
| 864 | | HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, |
| 865 | | switching behavior based on the nature of each request. |
| 866 | | </p> |
| 867 | | <div id="rfc.figure.u.4"></div><pre class="drawing"> > > > > |
| | 853 | </span></pre></div> |
| | 854 | <div id="implementation-diversity"> |
| | 855 | <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a href="#implementation-diversity">Implementation Diversity</a></h2> |
| | 856 | <p id="rfc.section.2.2.p.1">When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers |
| | 857 | and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household |
| | 858 | appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude |
| | 859 | of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components, |
| | 860 | office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms. |
| | 861 | </p> |
| | 862 | <p id="rfc.section.2.2.p.2">The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of |
| | 863 | a request. In many cases, a user agent is installed or configured to run in the background and save its results for later |
| | 864 | inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically |
| | 865 | given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph. |
| | 866 | </p> |
| | 867 | <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that we cannot assume the user agent can make interactive suggestions to a user |
| | 868 | or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting |
| | 869 | of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, |
| | 870 | requirements that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, |
| | 871 | run-time options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption |
| | 872 | of normal processing if the user has already made that choice. |
| | 873 | </p> |
| | 874 | </div> |
| | 875 | <div id="intermediaries"> |
| | 876 | <div id="rfc.iref.i.1"></div> |
| | 877 | <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a href="#intermediaries">Intermediaries</a></h2> |
| | 878 | <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of |
| | 879 | HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, |
| | 880 | switching behavior based on the nature of each request. |
| | 881 | </p> |
| | 882 | <div id="rfc.figure.u.4"></div><pre class="drawing"> > > > > |
| 871 | | message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply |
| 872 | | only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along |
| 873 | | the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For |
| 874 | | example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, |
| 875 | | at the same time that it is handling A's request. Likewise, later requests might be sent through a different path of connections, |
| 876 | | often based on dynamic configuration for load balancing. |
| 877 | | </p> |
| 878 | | <p id="rfc.section.2.3.p.4"><span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream. |
| 879 | | 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. |
| 880 | | </p> |
| 881 | | <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests |
| 882 | | for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations |
| 883 | | are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely |
| 884 | | different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary |
| 885 | | for the sake of security, annotation services, or shared caching. |
| 886 | | </p> |
| 887 | | <p id="rfc.section.2.3.p.6"><span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications, |
| 888 | | beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original |
| 889 | | sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared |
| 890 | | annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, |
| 891 | | or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) |
| 892 | | that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform |
| 893 | | 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 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations. |
| 894 | | </p> |
| 895 | | <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is an intermediary that acts as an origin server for the outbound connection, but translates received requests and forwards |
| 896 | | them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services, |
| 897 | | to improve server performance through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load balancing of HTTP services across multiple machines. |
| 898 | | </p> |
| 899 | | <p id="rfc.section.2.3.p.8">All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates |
| 900 | | with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of |
| 901 | | this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers ought to conform |
| 902 | | to user agent requirements on the gateway's inbound connection. |
| 903 | | </p> |
| 904 | | <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party |
| 905 | | to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both |
| 906 | | ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as |
| 907 | | when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy. |
| 908 | | </p> |
| 909 | | <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.3"></span> <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also |
| 910 | | intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the |
| 911 | | knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems |
| 912 | | by violating HTTP semantics. For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects |
| 913 | | outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public |
| 914 | | network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, |
| 915 | | and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack. |
| 916 | | </p> |
| 917 | | <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations |
| 918 | | depend on HTTP's stateless design in order to reuse proxied connections or dynamically load-balance requests across multiple |
| 919 | | servers. Hence, a server <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific |
| 920 | | to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems. |
| 921 | | </p> |
| 922 | | <div id="rfc.iref.c.4"></div> |
| 923 | | <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="caches" href="#caches">Caches</a></h2> |
| 924 | | <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. |
| 925 | | A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent |
| 926 | | 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. |
| 927 | | </p> |
| 928 | | <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached |
| 929 | | response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response |
| 930 | | from O (via C) for a request that has not been cached by UA or A. |
| 931 | | </p> |
| 932 | | <div id="rfc.figure.u.5"></div><pre class="drawing"> > > |
| | 886 | message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply |
| | 887 | only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along |
| | 888 | the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For |
| | 889 | example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, |
| | 890 | at the same time that it is handling A's request. Likewise, later requests might be sent through a different path of connections, |
| | 891 | often based on dynamic configuration for load balancing. |
| | 892 | </p> |
| | 893 | <p id="rfc.section.2.3.p.4"><span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream. |
| | 894 | 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. |
| | 895 | </p> |
| | 896 | <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests |
| | 897 | for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations |
| | 898 | are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely |
| | 899 | different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary |
| | 900 | for the sake of security, annotation services, or shared caching. |
| | 901 | </p> |
| | 902 | <p id="rfc.section.2.3.p.6"><span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications, |
| | 903 | beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original |
| | 904 | sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared |
| | 905 | annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, |
| | 906 | or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) |
| | 907 | that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform |
| | 908 | 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 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations. |
| | 909 | </p> |
| | 910 | <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is an intermediary that acts as an origin server for the outbound connection, but translates received requests and forwards |
| | 911 | them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services, |
| | 912 | to improve server performance through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load balancing of HTTP services across multiple machines. |
| | 913 | </p> |
| | 914 | <p id="rfc.section.2.3.p.8">All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates |
| | 915 | with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of |
| | 916 | this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers ought to conform |
| | 917 | to user agent requirements on the gateway's inbound connection. |
| | 918 | </p> |
| | 919 | <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party |
| | 920 | to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both |
| | 921 | ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as |
| | 922 | when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy. |
| | 923 | </p> |
| | 924 | <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.3"></span> <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also |
| | 925 | intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the |
| | 926 | knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems |
| | 927 | by violating HTTP semantics. For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects |
| | 928 | outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public |
| | 929 | network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, |
| | 930 | and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack. |
| | 931 | </p> |
| | 932 | <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations |
| | 933 | depend on HTTP's stateless design in order to reuse proxied connections or dynamically load-balance requests across multiple |
| | 934 | servers. Hence, a server <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific |
| | 935 | to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems. |
| | 936 | </p> |
| | 937 | </div> |
| | 938 | <div id="caches"> |
| | 939 | <div id="rfc.iref.c.4"></div> |
| | 940 | <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a href="#caches">Caches</a></h2> |
| | 941 | <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. |
| | 942 | A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent |
| | 943 | 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. |
| | 944 | </p> |
| | 945 | <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached |
| | 946 | response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response |
| | 947 | from O (via C) for a request that has not been cached by UA or A. |
| | 948 | </p> |
| | 949 | <div id="rfc.figure.u.5"></div><pre class="drawing"> > > |
| 936 | | is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response |
| 937 | | can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. |
| 938 | | </p> |
| 939 | | <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large |
| 940 | | organizations. These include national hierarchies of proxy caches to save transoceanic bandwidth, collaborative systems that |
| 941 | | broadcast or multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, |
| 942 | | and so on. |
| 943 | | </p> |
| 944 | | <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="conformance" href="#conformance">Conformance and Error Handling</a></h2> |
| 945 | | <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP |
| 946 | | requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, |
| 947 | | or caches, depending on what behavior is being constrained by the requirement. Additional (social) requirements are placed |
| 948 | | on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication. |
| 949 | | </p> |
| 950 | | <p id="rfc.section.2.5.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely |
| 951 | | forwarding a received element downstream. |
| 952 | | </p> |
| 953 | | <p id="rfc.section.2.5.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes |
| 954 | | in HTTP. |
| 955 | | </p> |
| 956 | | <p id="rfc.section.2.5.p.4">Conformance includes both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message, |
| 957 | | a sender <em class="bcp14">MUST NOT</em> generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., |
| 958 | | a role that the sender does not have for that message). |
| 959 | | </p> |
| 960 | | <p id="rfc.section.2.5.p.5">When a received protocol element is parsed, the recipient <em class="bcp14">MUST</em> be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined |
| 961 | | by the corresponding ABNF rules. Note, however, that some received protocol elements might not be parsed. For example, an |
| 962 | | intermediary forwarding a message might parse a header-field into generic field-name and field-value components, but then |
| 963 | | forward the header field without further parsing inside the field-value. |
| 964 | | </p> |
| 965 | | <p id="rfc.section.2.5.p.6">HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate |
| 966 | | will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders |
| 967 | | and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, |
| 968 | | what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two |
| 969 | | decades of HTTP use, and is expected to continue changing in the future. |
| 970 | | </p> |
| 971 | | <p id="rfc.section.2.5.p.7">At a minimum, a recipient <em class="bcp14">MUST</em> be able to parse and process protocol element lengths that are at least as long as the values that it generates for those |
| 972 | | same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own |
| 973 | | resources needs to be able to parse and process those same references when received as a request target. |
| 974 | | </p> |
| 975 | | <p id="rfc.section.2.5.p.8">A recipient <em class="bcp14">MUST</em> interpret a received protocol element according to the semantics defined for it by this specification, including extensions |
| 976 | | to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly |
| 977 | | implements what is implied by those semantics. For example, an origin server might disregard the contents of a received <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> header field if inspection of the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> header field indicates a specific implementation version that is known to fail on receipt of certain content codings. |
| 978 | | </p> |
| 979 | | <p id="rfc.section.2.5.p.9">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms |
| 980 | | except when they have a direct impact on security, since different applications of the protocol require different error handling |
| 981 | | strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery |
| 982 | | to be dangerous. |
| 983 | | </p> |
| 984 | | <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="http.version" href="#http.version">Protocol Versioning</a></h2> |
| 985 | | <p id="rfc.section.2.6.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". |
| 986 | | The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's |
| 987 | | corresponding specification of HTTP. |
| 988 | | </p> |
| 989 | | <p id="rfc.section.2.6.p.2">The version of an HTTP message is indicated by an HTTP-version field in the first line of the message. HTTP-version is case-sensitive.</p> |
| 990 | | <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#http.version" class="smpl">HTTP-version</a> = <a href="#http.version" class="smpl">HTTP-name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a> |
| | 953 | is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response |
| | 954 | can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. |
| | 955 | </p> |
| | 956 | <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large |
| | 957 | organizations. These include national hierarchies of proxy caches to save transoceanic bandwidth, collaborative systems that |
| | 958 | broadcast or multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, |
| | 959 | and so on. |
| | 960 | </p> |
| | 961 | </div> |
| | 962 | <div id="conformance"> |
| | 963 | <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a href="#conformance">Conformance and Error Handling</a></h2> |
| | 964 | <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP |
| | 965 | requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, |
| | 966 | or caches, depending on what behavior is being constrained by the requirement. Additional (social) requirements are placed |
| | 967 | on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication. |
| | 968 | </p> |
| | 969 | <p id="rfc.section.2.5.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely |
| | 970 | forwarding a received element downstream. |
| | 971 | </p> |
| | 972 | <p id="rfc.section.2.5.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes |
| | 973 | in HTTP. |
| | 974 | </p> |
| | 975 | <p id="rfc.section.2.5.p.4">Conformance includes both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message, |
| | 976 | a sender <em class="bcp14">MUST NOT</em> generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., |
| | 977 | a role that the sender does not have for that message). |
| | 978 | </p> |
| | 979 | <p id="rfc.section.2.5.p.5">When a received protocol element is parsed, the recipient <em class="bcp14">MUST</em> be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined |
| | 980 | by the corresponding ABNF rules. Note, however, that some received protocol elements might not be parsed. For example, an |
| | 981 | intermediary forwarding a message might parse a header-field into generic field-name and field-value components, but then |
| | 982 | forward the header field without further parsing inside the field-value. |
| | 983 | </p> |
| | 984 | <p id="rfc.section.2.5.p.6">HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate |
| | 985 | will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders |
| | 986 | and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, |
| | 987 | what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two |
| | 988 | decades of HTTP use, and is expected to continue changing in the future. |
| | 989 | </p> |
| | 990 | <p id="rfc.section.2.5.p.7">At a minimum, a recipient <em class="bcp14">MUST</em> be able to parse and process protocol element lengths that are at least as long as the values that it generates for those |
| | 991 | same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own |
| | 992 | resources needs to be able to parse and process those same references when received as a request target. |
| | 993 | </p> |
| | 994 | <p id="rfc.section.2.5.p.8">A recipient <em class="bcp14">MUST</em> interpret a received protocol element according to the semantics defined for it by this specification, including extensions |
| | 995 | to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly |
| | 996 | implements what is implied by those semantics. For example, an origin server might disregard the contents of a received <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> header field if inspection of the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> header field indicates a specific implementation version that is known to fail on receipt of certain content codings. |
| | 997 | </p> |
| | 998 | <p id="rfc.section.2.5.p.9">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms |
| | 999 | except when they have a direct impact on security, since different applications of the protocol require different error handling |
| | 1000 | strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery |
| | 1001 | to be dangerous. |
| | 1002 | </p> |
| | 1003 | </div> |
| | 1004 | <div id="http.version"> |
| | 1005 | <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a href="#http.version">Protocol Versioning</a></h2> |
| | 1006 | <p id="rfc.section.2.6.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". |
| | 1007 | The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's |
| | 1008 | corresponding specification of HTTP. |
| | 1009 | </p> |
| | 1010 | <p id="rfc.section.2.6.p.2">The version of an HTTP message is indicated by an HTTP-version field in the first line of the message. HTTP-version is case-sensitive.</p> |
| | 1011 | <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#http.version" class="smpl">HTTP-version</a> = <a href="#http.version" class="smpl">HTTP-name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a> |
| 993 | | version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version |
| 994 | | within that major version to which the sender is conformant and able to understand for future communication. The minor version |
| 995 | | advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the |
| 996 | | protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future |
| 997 | | requests (by clients). |
| 998 | | </p> |
| 999 | | <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 |
| 1000 | | message if all of the newer features are ignored. This specification places recipient-version requirements on some new features |
| 1001 | | so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt |
| 1002 | | of a message, that the recipient supports HTTP/1.1. |
| 1003 | | </p> |
| 1004 | | <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default |
| 1005 | | behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 |
| 1006 | | are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. |
| 1007 | | </p> |
| 1008 | | <p id="rfc.section.2.6.p.7">New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely |
| 1009 | | ignored by recipients that do not recognize them. Header field extensibility is discussed in <a href="#field.extensibility" title="Field Extensibility">Section 3.2.1</a>. |
| 1010 | | </p> |
| 1011 | | <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version |
| 1012 | | to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without |
| 1013 | | rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version |
| 1014 | | to determine what features are safe to use for later communication with that sender. |
| 1015 | | </p> |
| 1016 | | <p id="rfc.section.2.6.p.9">A client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher |
| 1017 | | than the highest version supported by the server, if this is known. A client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. |
| 1018 | | </p> |
| 1019 | | <p id="rfc.section.2.6.p.10">A 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 |
| 1020 | | the client has attempted at least one normal request and determined from the response status code or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions. |
| 1021 | | </p> |
| 1022 | | <p id="rfc.section.2.6.p.11">A server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than |
| 1023 | | or equal to the one received in the request. A server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not |
| 1024 | | Supported)</a> response if it cannot send a response using the major version used in the client's request. |
| 1025 | | </p> |
| 1026 | | <p id="rfc.section.2.6.p.12">A server <em class="bcp14">MAY</em> send an HTTP/1.0 response to a request if it is known or suspected that the client incorrectly implements the HTTP specification |
| 1027 | | and is incapable of correctly processing later version responses, such as when a client fails to parse the version number |
| 1028 | | correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor |
| 1029 | | version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error. |
| 1030 | | </p> |
| 1031 | | <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 |
| 1032 | | is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding |
| 1033 | | to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented |
| 1034 | | for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision has specifically avoided any such changes to the protocol. |
| 1035 | | </p> |
| 1036 | | <p id="rfc.section.2.6.p.14">When an HTTP message is received with a major version number that the recipient implements, but a higher minor version number |
| 1037 | | than what the recipient implements, the recipient <em class="bcp14">SHOULD</em> process the message as if it were in the highest minor version within that major version to which the recipient is conformant. |
| 1038 | | A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support |
| 1039 | | for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major |
| 1040 | | version. |
| 1041 | | </p> |
| 1042 | | <div id="rfc.iref.r.5"></div> |
| 1043 | | <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> |
| 1044 | | <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 (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships. |
| 1045 | | </p> |
| 1046 | | <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", |
| 1047 | | "path-abempty", "segment", "query", and "fragment" from the URI generic syntax. In addition, we define an "absolute-path" |
| 1048 | | rule (that differs from RFC 3986's "path-absolute" in that it allows a leading "//") and a "partial-URI" rule for protocol |
| 1049 | | elements that allow a relative URI but not a fragment. |
| 1050 | | </p> |
| 1051 | | <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><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.3"><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>> |
| | 1014 | version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version |
| | 1015 | within that major version to which the sender is conformant and able to understand for future communication. The minor version |
| | 1016 | advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the |
| | 1017 | protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future |
| | 1018 | requests (by clients). |
| | 1019 | </p> |
| | 1020 | <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 |
| | 1021 | message if all of the newer features are ignored. This specification places recipient-version requirements on some new features |
| | 1022 | so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt |
| | 1023 | of a message, that the recipient supports HTTP/1.1. |
| | 1024 | </p> |
| | 1025 | <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default |
| | 1026 | behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 |
| | 1027 | are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. |
| | 1028 | </p> |
| | 1029 | <p id="rfc.section.2.6.p.7">New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely |
| | 1030 | ignored by recipients that do not recognize them. Header field extensibility is discussed in <a href="#field.extensibility" title="Field Extensibility">Section 3.2.1</a>. |
| | 1031 | </p> |
| | 1032 | <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version |
| | 1033 | to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without |
| | 1034 | rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version |
| | 1035 | to determine what features are safe to use for later communication with that sender. |
| | 1036 | </p> |
| | 1037 | <p id="rfc.section.2.6.p.9">A client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher |
| | 1038 | than the highest version supported by the server, if this is known. A client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. |
| | 1039 | </p> |
| | 1040 | <p id="rfc.section.2.6.p.10">A 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 |
| | 1041 | the client has attempted at least one normal request and determined from the response status code or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions. |
| | 1042 | </p> |
| | 1043 | <p id="rfc.section.2.6.p.11">A server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than |
| | 1044 | or equal to the one received in the request. A server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not |
| | 1045 | Supported)</a> response if it cannot send a response using the major version used in the client's request. |
| | 1046 | </p> |
| | 1047 | <p id="rfc.section.2.6.p.12">A server <em class="bcp14">MAY</em> send an HTTP/1.0 response to a request if it is known or suspected that the client incorrectly implements the HTTP specification |
| | 1048 | and is incapable of correctly processing later version responses, such as when a client fails to parse the version number |
| | 1049 | correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor |
| | 1050 | version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error. |
| | 1051 | </p> |
| | 1052 | <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 |
| | 1053 | is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding |
| | 1054 | to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented |
| | 1055 | for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision has specifically avoided any such changes to the protocol. |
| | 1056 | </p> |
| | 1057 | <p id="rfc.section.2.6.p.14">When an HTTP message is received with a major version number that the recipient implements, but a higher minor version number |
| | 1058 | than what the recipient implements, the recipient <em class="bcp14">SHOULD</em> process the message as if it were in the highest minor version within that major version to which the recipient is conformant. |
| | 1059 | A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support |
| | 1060 | for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major |
| | 1061 | version. |
| | 1062 | </p> |
| | 1063 | </div> |
| | 1064 | <div id="uri"> |
| | 1065 | <div id="rfc.iref.r.5"></div> |
| | 1066 | <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a href="#uri">Uniform Resource Identifiers</a></h2> |
| | 1067 | <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 (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships. |
| | 1068 | </p> |
| | 1069 | <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", |
| | 1070 | "path-abempty", "segment", "query", and "fragment" from the URI generic syntax. In addition, we define an "absolute-path" |
| | 1071 | rule (that differs from RFC 3986's "path-absolute" in that it allows a leading "//") and a "partial-URI" rule for protocol |
| | 1072 | elements that allow a relative URI but not a fragment. |
| | 1073 | </p> |
| | 1074 | <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><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.3"><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>> |
| 1078 | | identifier for a potential resource within that origin server's name space. |
| 1079 | | </p> |
| 1080 | | <p id="rfc.section.2.7.1.p.4">A sender <em class="bcp14">MUST NOT</em> generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference <em class="bcp14">MUST</em> reject it as invalid. |
| 1081 | | </p> |
| 1082 | | <p id="rfc.section.2.7.1.p.5">If the host identifier is provided as an IP address, then the origin server is any listener on the indicated TCP port at that |
| 1083 | | IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might use |
| 1084 | | a name resolution service, such as DNS, to find the address of a listener for that host. If the port subcomponent is empty |
| 1085 | | or not given, then TCP port 80 is assumed (the default reserved port for WWW services). |
| 1086 | | </p> |
| 1087 | | <p id="rfc.section.2.7.1.p.6">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address. |
| 1088 | | The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening |
| 1089 | | to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish |
| 1090 | | a naming authority (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that |
| 1091 | | authority to determine which names are valid and how they might be used. |
| 1092 | | </p> |
| 1093 | | <p id="rfc.section.2.7.1.p.7">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, |
| 1094 | | and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. |
| 1095 | | </p> |
| 1096 | | <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name |
| 1097 | | delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol |
| 1098 | | would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that |
| 1099 | | require an end-to-end secured connection. Other protocols might also be used to provide access to "http" identified resources |
| 1100 | | — it is only the authoritative interface that is specific to TCP. |
| 1101 | | </p> |
| 1102 | | <p id="rfc.section.2.7.1.p.9">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<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.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal |
| 1103 | | configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, |
| 1104 | | even though such usage might expose a user identifier or password. A sender <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a |
| 1105 | | request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient |
| 1106 | | ought to parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake |
| 1107 | | of phishing attacks. |
| 1108 | | </p> |
| 1109 | | <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> |
| 1110 | | <div id="rfc.iref.h.2"></div> |
| 1111 | | <div id="rfc.iref.u.4"></div> |
| 1112 | | <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 |
| 1113 | | namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections (<a href="#RFC0793" id="rfc.xref.RFC0793.2"><cite title="Transmission Control Protocol">[RFC0793]</cite></a>, <a href="#RFC5246" id="rfc.xref.RFC5246.2"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>). |
| 1114 | | </p> |
| 1115 | | <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 |
| 1116 | | TCP port of 443 is assumed if the port subcomponent is empty or not given, and the user agent <em class="bcp14">MUST</em> ensure that its connection to the origin server is secured through the use of strong encryption, end-to-end, prior to sending |
| 1117 | | the first HTTP request. |
| 1118 | | </p> |
| 1119 | | <div id="rfc.figure.u.9"></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> ] |
| | 1102 | identifier for a potential resource within that origin server's name space. |
| | 1103 | </p> |
| | 1104 | <p id="rfc.section.2.7.1.p.4">A sender <em class="bcp14">MUST NOT</em> generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference <em class="bcp14">MUST</em> reject it as invalid. |
| | 1105 | </p> |
| | 1106 | <p id="rfc.section.2.7.1.p.5">If the host identifier is provided as an IP address, then the origin server is any listener on the indicated TCP port at that |
| | 1107 | IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might use |
| | 1108 | a name resolution service, such as DNS, to find the address of a listener for that host. If the port subcomponent is empty |
| | 1109 | or not given, then TCP port 80 is assumed (the default reserved port for WWW services). |
| | 1110 | </p> |
| | 1111 | <p id="rfc.section.2.7.1.p.6">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address. |
| | 1112 | The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening |
| | 1113 | to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish |
| | 1114 | a naming authority (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that |
| | 1115 | authority to determine which names are valid and how they might be used. |
| | 1116 | </p> |
| | 1117 | <p id="rfc.section.2.7.1.p.7">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, |
| | 1118 | and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. |
| | 1119 | </p> |
| | 1120 | <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name |
| | 1121 | delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol |
| | 1122 | would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that |
| | 1123 | require an end-to-end secured connection. Other protocols might also be used to provide access to "http" identified resources |
| | 1124 | — it is only the authoritative interface that is specific to TCP. |
| | 1125 | </p> |
| | 1126 | <p id="rfc.section.2.7.1.p.9">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<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.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal |
| | 1127 | configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, |
| | 1128 | even though such usage might expose a user identifier or password. A sender <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a |
| | 1129 | request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient |
| | 1130 | ought to parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake |
| | 1131 | of phishing attacks. |
| | 1132 | </p> |
| | 1133 | </div> |
| | 1134 | <div id="https.uri"> |
| | 1135 | <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> |
| | 1136 | <div id="rfc.iref.h.2"></div> |
| | 1137 | <div id="rfc.iref.u.4"></div> |
| | 1138 | <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 |
| | 1139 | namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections (<a href="#RFC0793" id="rfc.xref.RFC0793.2"><cite title="Transmission Control Protocol">[RFC0793]</cite></a>, <a href="#RFC5246" id="rfc.xref.RFC5246.2"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>). |
| | 1140 | </p> |
| | 1141 | <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 |
| | 1142 | TCP port of 443 is assumed if the port subcomponent is empty or not given, and the user agent <em class="bcp14">MUST</em> ensure that its connection to the origin server is secured through the use of strong encryption, end-to-end, prior to sending |
| | 1143 | the first HTTP request. |
| | 1144 | </p> |
| | 1145 | <div id="rfc.figure.u.9"></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> ] |
| 1155 | | hash table by field name until the empty line, and then use the parsed data to determine if a message body is expected. If |
| 1156 | | a message body has been indicated, then it is read as a stream until an amount of octets equal to the message body length |
| 1157 | | is read or the connection is closed. |
| 1158 | | </p> |
| 1159 | | <p id="rfc.section.3.p.4">A recipient <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities |
| 1160 | | due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet |
| 1161 | | LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from |
| 1162 | | the message, such as within a header field-value after message parsing has delineated the individual fields. |
| 1163 | | </p> |
| 1164 | | <p id="rfc.section.3.p.5">An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, recipients cannot |
| 1165 | | rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the |
| 1166 | | sake of network efficiency, security checks, or payload transformations. |
| 1167 | | </p> |
| 1168 | | <p id="rfc.section.3.p.6">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. A recipient that receives whitespace between the start-line |
| 1169 | | and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore |
| 1170 | | the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received |
| 1171 | | or the header section is terminated). |
| 1172 | | </p> |
| 1173 | | <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing |
| 1174 | | the line after it as a new request, either of which might result in a security vulnerability if other implementations within |
| 1175 | | the request chain interpret the same message differently. Likewise, the presence of such whitespace in a response might be |
| 1176 | | ignored by some clients or cause others to cease parsing. |
| 1177 | | </p> |
| 1178 | | <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="start.line" href="#start.line">Start Line</a></h2> |
| 1179 | | <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two |
| 1180 | | types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), |
| 1181 | | and in the algorithm for determining the length of the message body (<a href="#message.body" title="Message Body">Section 3.3</a>). |
| 1182 | | </p> |
| 1183 | | <p id="rfc.section.3.1.p.2">In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line |
| 1184 | | formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown or invalid |
| 1185 | | request method) and clients are implemented to only expect a response. |
| 1186 | | </p> |
| 1187 | | <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a> |
| 1188 | | </pre><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="request.line" href="#request.line">Request Line</a></h3> |
| 1189 | | <p id="rfc.section.3.1.1.p.1">A request-line begins with a method token, followed by a single space (SP), the request-target, another single space (SP), |
| 1190 | | the protocol version, and ending with CRLF. |
| 1191 | | </p> |
| 1192 | | <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#request.line" class="smpl">request-line</a> = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a> |
| | 1187 | hash table by field name until the empty line, and then use the parsed data to determine if a message body is expected. If |
| | 1188 | a message body has been indicated, then it is read as a stream until an amount of octets equal to the message body length |
| | 1189 | is read or the connection is closed. |
| | 1190 | </p> |
| | 1191 | <p id="rfc.section.3.p.4">A recipient <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities |
| | 1192 | due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet |
| | 1193 | LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from |
| | 1194 | the message, such as within a header field-value after message parsing has delineated the individual fields. |
| | 1195 | </p> |
| | 1196 | <p id="rfc.section.3.p.5">An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, recipients cannot |
| | 1197 | rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the |
| | 1198 | sake of network efficiency, security checks, or payload transformations. |
| | 1199 | </p> |
| | 1200 | <p id="rfc.section.3.p.6">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. A recipient that receives whitespace between the start-line |
| | 1201 | and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore |
| | 1202 | the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received |
| | 1203 | or the header section is terminated). |
| | 1204 | </p> |
| | 1205 | <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing |
| | 1206 | the line after it as a new request, either of which might result in a security vulnerability if other implementations within |
| | 1207 | the request chain interpret the same message differently. Likewise, the presence of such whitespace in a response might be |
| | 1208 | ignored by some clients or cause others to cease parsing. |
| | 1209 | </p> |
| | 1210 | <div id="start.line"> |
| | 1211 | <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a href="#start.line">Start Line</a></h2> |
| | 1212 | <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two |
| | 1213 | types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), |
| | 1214 | and in the algorithm for determining the length of the message body (<a href="#message.body" title="Message Body">Section 3.3</a>). |
| | 1215 | </p> |
| | 1216 | <p id="rfc.section.3.1.p.2">In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line |
| | 1217 | formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown or invalid |
| | 1218 | request method) and clients are implemented to only expect a response. |
| | 1219 | </p> |
| | 1220 | <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a> |
| | 1221 | </pre><div id="request.line"> |
| | 1222 | <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a href="#request.line">Request Line</a></h3> |
| | 1223 | <p id="rfc.section.3.1.1.p.1">A request-line begins with a method token, followed by a single space (SP), the request-target, another single space (SP), |
| | 1224 | the protocol version, and ending with CRLF. |
| | 1225 | </p> |
| | 1226 | <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#request.line" class="smpl">request-line</a> = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a> |
| 1242 | | the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. |
| 1243 | | </p> |
| 1244 | | <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3> |
| 1245 | | <p id="rfc.section.3.2.1.p.1">Header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new |
| 1246 | | semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification |
| 1247 | | and in many other specifications outside the core standard. |
| 1248 | | </p> |
| 1249 | | <p id="rfc.section.3.2.1.p.2">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation |
| 1250 | | of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses. |
| 1251 | | </p> |
| 1252 | | <p id="rfc.section.3.2.1.p.3">A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. These requirements allow HTTP's functionality to be enhanced without requiring prior update |
| 1253 | | of deployed intermediaries. |
| 1254 | | </p> |
| 1255 | | <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. |
| 1256 | | </p> |
| 1257 | | <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.order" href="#field.order">Field Order</a></h3> |
| 1258 | | <p id="rfc.section.3.2.2.p.1">The order in which header fields with differing field names are received is not significant. However, it is "good practice" |
| 1259 | | to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include |
| 1260 | | conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. |
| 1261 | | </p> |
| 1262 | | <p id="rfc.section.3.2.2.p.2">A sender <em class="bcp14">MUST NOT</em> generate multiple header fields with the same field name in a message unless either the entire field value for that header |
| 1263 | | field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). |
| 1264 | | </p> |
| 1265 | | <p id="rfc.section.3.2.2.p.3">A recipient <em class="bcp14">MAY</em> combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics |
| 1266 | | of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order |
| 1267 | | in which header fields with the same field name are received is therefore significant to the interpretation of the combined |
| 1268 | | field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. |
| 1269 | | </p> |
| 1270 | | <div class="note" id="rfc.section.3.2.2.p.4"> |
| 1271 | | <p><b>Note:</b> In practice, the "Set-Cookie" header field (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on |
| 1272 | | multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle |
| 1273 | | "Set-Cookie" as a special case while processing header fields. (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.) |
| 1274 | | </p> |
| 1275 | | </div> |
| 1276 | | <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="whitespace" href="#whitespace">Whitespace</a></h3> |
| 1277 | | <div id="rule.LWS"> |
| 1278 | | <p id="rfc.section.3.2.3.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), |
| 1279 | | and BWS ("bad" whitespace). |
| 1280 | | </p> |
| 1281 | | </div> |
| 1282 | | <div id="rule.OWS"> |
| 1283 | | <p id="rfc.section.3.2.3.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements where optional whitespace |
| 1284 | | is preferred to improve readability, a sender <em class="bcp14">SHOULD</em> generate the optional whitespace as a single SP; otherwise, a sender <em class="bcp14">SHOULD NOT</em> generate optional whitespace except as needed to white-out invalid or unwanted protocol elements during in-place message filtering. |
| 1285 | | </p> |
| 1286 | | </div> |
| 1287 | | <div id="rule.RWS"> |
| 1288 | | <p id="rfc.section.3.2.3.p.3">The RWS rule is used when at least one linear whitespace octet is required to separate field tokens. A sender <em class="bcp14">SHOULD</em> generate RWS as a single SP. |
| 1289 | | </p> |
| 1290 | | </div> |
| 1291 | | <div id="rule.BWS"> |
| 1292 | | <p id="rfc.section.3.2.3.p.4">The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender <em class="bcp14">MUST NOT</em> generate BWS in messages. A recipient <em class="bcp14">MUST</em> parse for such bad whitespace and remove it before interpreting the protocol element. |
| 1293 | | </p> |
| 1294 | | </div> |
| 1295 | | <div id="rule.whitespace"> |
| 1296 | | <p id="rfc.section.3.2.3.p.5"> </p> |
| 1297 | | </div> |
| 1298 | | <div id="rfc.figure.u.19"></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> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) |
| | 1281 | the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. |
| | 1282 | </p> |
| | 1283 | <div id="field.extensibility"> |
| | 1284 | <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#field.extensibility">Field Extensibility</a></h3> |
| | 1285 | <p id="rfc.section.3.2.1.p.1">Header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new |
| | 1286 | semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification |
| | 1287 | and in many other specifications outside the core standard. |
| | 1288 | </p> |
| | 1289 | <p id="rfc.section.3.2.1.p.2">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation |
| | 1290 | of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses. |
| | 1291 | </p> |
| | 1292 | <p id="rfc.section.3.2.1.p.3">A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. These requirements allow HTTP's functionality to be enhanced without requiring prior update |
| | 1293 | of deployed intermediaries. |
| | 1294 | </p> |
| | 1295 | <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. |
| | 1296 | </p> |
| | 1297 | </div> |
| | 1298 | <div id="field.order"> |
| | 1299 | <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#field.order">Field Order</a></h3> |
| | 1300 | <p id="rfc.section.3.2.2.p.1">The order in which header fields with differing field names are received is not significant. However, it is "good practice" |
| | 1301 | to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include |
| | 1302 | conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. |
| | 1303 | </p> |
| | 1304 | <p id="rfc.section.3.2.2.p.2">A sender <em class="bcp14">MUST NOT</em> generate multiple header fields with the same field name in a message unless either the entire field value for that header |
| | 1305 | field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). |
| | 1306 | </p> |
| | 1307 | <p id="rfc.section.3.2.2.p.3">A recipient <em class="bcp14">MAY</em> combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics |
| | 1308 | of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order |
| | 1309 | in which header fields with the same field name are received is therefore significant to the interpretation of the combined |
| | 1310 | field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. |
| | 1311 | </p> |
| | 1312 | <div class="note" id="rfc.section.3.2.2.p.4"> |
| | 1313 | <p><b>Note:</b> In practice, the "Set-Cookie" header field (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on |
| | 1314 | multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle |
| | 1315 | "Set-Cookie" as a special case while processing header fields. (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.) |
| | 1316 | </p> |
| | 1317 | </div> |
| | 1318 | </div> |
| | 1319 | <div id="whitespace"> |
| | 1320 | <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#whitespace">Whitespace</a></h3> |
| | 1321 | <div id="rule.LWS"> |
| | 1322 | <p id="rfc.section.3.2.3.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), |
| | 1323 | and BWS ("bad" whitespace). |
| | 1324 | </p> |
| | 1325 | </div> |
| | 1326 | <div id="rule.OWS"> |
| | 1327 | <p id="rfc.section.3.2.3.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements where optional whitespace |
| | 1328 | is preferred to improve readability, a sender <em class="bcp14">SHOULD</em> generate the optional whitespace as a single SP; otherwise, a sender <em class="bcp14">SHOULD NOT</em> generate optional whitespace except as needed to white-out invalid or unwanted protocol elements during in-place message filtering. |
| | 1329 | </p> |
| | 1330 | </div> |
| | 1331 | <div id="rule.RWS"> |
| | 1332 | <p id="rfc.section.3.2.3.p.3">The RWS rule is used when at least one linear whitespace octet is required to separate field tokens. A sender <em class="bcp14">SHOULD</em> generate RWS as a single SP. |
| | 1333 | </p> |
| | 1334 | </div> |
| | 1335 | <div id="rule.BWS"> |
| | 1336 | <p id="rfc.section.3.2.3.p.4">The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender <em class="bcp14">MUST NOT</em> generate BWS in messages. A recipient <em class="bcp14">MUST</em> parse for such bad whitespace and remove it before interpreting the protocol element. |
| | 1337 | </p> |
| | 1338 | </div> |
| | 1339 | <div id="rule.whitespace"> |
| | 1340 | <p id="rfc.section.3.2.3.p.5"> </p> |
| | 1341 | </div> |
| | 1342 | <div id="rfc.figure.u.19"></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> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) |
| 1304 | | </pre><h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3> |
| 1305 | | <p id="rfc.section.3.2.4.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace |
| 1306 | | have led to security vulnerabilities in request routing and response handling. A server <em class="bcp14">MUST</em> reject any received request message that contains whitespace between a header field-name and colon with a response code of <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>. A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. |
| 1307 | | </p> |
| 1308 | | <p id="rfc.section.3.2.4.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading |
| 1309 | | or trailing white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace |
| 1310 | | octet of the field value ought to be excluded by parsers when extracting the field value from a header field. |
| 1311 | | </p> |
| 1312 | | <p id="rfc.section.3.2.4.p.3">A recipient of field-content containing multiple sequential octets of optional (OWS) or required (RWS) whitespace <em class="bcp14">SHOULD</em> either replace the sequence with a single SP or transform any non-SP octets in the sequence to SP octets before interpreting |
| 1313 | | the field value or forwarding the message downstream. |
| 1314 | | </p> |
| 1315 | | <p id="rfc.section.3.2.4.p.4">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one |
| 1316 | | space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type |
| 1317 | | (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a>). A sender <em class="bcp14">MUST NOT</em> generate a message that includes line folding (i.e., that has any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type. |
| 1318 | | </p> |
| 1319 | | <p id="rfc.section.3.2.4.p.5">A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream. |
| 1320 | | </p> |
| 1321 | | <p id="rfc.section.3.2.4.p.6">A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream. |
| 1322 | | </p> |
| 1323 | | <p id="rfc.section.3.2.4.p.7">A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value. |
| 1324 | | </p> |
| 1325 | | <p id="rfc.section.3.2.4.p.8">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> charset, supporting other charsets 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 charset <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. A recipient <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data. |
| 1326 | | </p> |
| 1327 | | <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a id="field.limits" href="#field.limits">Field Limits</a></h3> |
| 1328 | | <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header section as a whole, |
| 1329 | | as described in <a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field |
| 1330 | | semantics. |
| 1331 | | </p> |
| 1332 | | <p id="rfc.section.3.2.5.p.2">A server ought to be prepared to receive request header fields of unbounded length and <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process. |
| 1333 | | </p> |
| 1334 | | <p id="rfc.section.3.2.5.p.3">A client ought to be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such |
| 1335 | | that the dropped value(s) can be safely ignored without changing the message framing or response semantics. |
| 1336 | | </p> |
| 1337 | | <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a> <a id="field.components" href="#field.components">Field value components</a></h3> |
| 1338 | | <div id="rule.token.separators"> |
| 1339 | | <p id="rfc.section.3.2.6.p.1"> Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters.</p> |
| 1340 | | </div> |
| 1341 | | <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></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> |
| | 1348 | </pre></div> |
| | 1349 | <div id="field.parsing"> |
| | 1350 | <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a href="#field.parsing">Field Parsing</a></h3> |
| | 1351 | <p id="rfc.section.3.2.4.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace |
| | 1352 | have led to security vulnerabilities in request routing and response handling. A server <em class="bcp14">MUST</em> reject any received request message that contains whitespace between a header field-name and colon with a response code of <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>. A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. |
| | 1353 | </p> |
| | 1354 | <p id="rfc.section.3.2.4.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading |
| | 1355 | or trailing white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace |
| | 1356 | octet of the field value ought to be excluded by parsers when extracting the field value from a header field. |
| | 1357 | </p> |
| | 1358 | <p id="rfc.section.3.2.4.p.3">A recipient of field-content containing multiple sequential octets of optional (OWS) or required (RWS) whitespace <em class="bcp14">SHOULD</em> either replace the sequence with a single SP or transform any non-SP octets in the sequence to SP octets before interpreting |
| | 1359 | the field value or forwarding the message downstream. |
| | 1360 | </p> |
| | 1361 | <p id="rfc.section.3.2.4.p.4">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one |
| | 1362 | space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type |
| | 1363 | (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a>). A sender <em class="bcp14">MUST NOT</em> generate a message that includes line folding (i.e., that has any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type. |
| | 1364 | </p> |
| | 1365 | <p id="rfc.section.3.2.4.p.5">A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream. |
| | 1366 | </p> |
| | 1367 | <p id="rfc.section.3.2.4.p.6">A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream. |
| | 1368 | </p> |
| | 1369 | <p id="rfc.section.3.2.4.p.7">A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value. |
| | 1370 | </p> |
| | 1371 | <p id="rfc.section.3.2.4.p.8">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> charset, supporting other charsets 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 charset <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. A recipient <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data. |
| | 1372 | </p> |
| | 1373 | </div> |
| | 1374 | <div id="field.limits"> |
| | 1375 | <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a href="#field.limits">Field Limits</a></h3> |
| | 1376 | <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header section as a whole, |
| | 1377 | as described in <a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field |
| | 1378 | semantics. |
| | 1379 | </p> |
| | 1380 | <p id="rfc.section.3.2.5.p.2">A server ought to be prepared to receive request header fields of unbounded length and <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process. |
| | 1381 | </p> |
| | 1382 | <p id="rfc.section.3.2.5.p.3">A client ought to be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such |
| | 1383 | that the dropped value(s) can be safely ignored without changing the message framing or response semantics. |
| | 1384 | </p> |
| | 1385 | </div> |
| | 1386 | <div id="field.components"> |
| | 1387 | <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a> <a href="#field.components">Field value components</a></h3> |
| | 1388 | <div id="rule.token.separators"> |
| | 1389 | <p id="rfc.section.3.2.6.p.1"> Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters.</p> |
| | 1390 | </div> |
| | 1391 | <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></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> |
| 1376 | | <p id="rfc.section.3.2.6.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> |
| | 1426 | <p id="rfc.section.3.2.6.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> |
| | 1427 | </div> |
| | 1428 | <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.53"></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> ) |
| | 1429 | </pre><p id="rfc.section.3.2.6.p.13">A sender <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 |
| | 1430 | ")"). |
| | 1431 | </p> |
| | 1432 | </div> |
| | 1433 | </div> |
| | 1434 | <div id="message.body"> |
| | 1435 | <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a href="#message.body">Message Body</a></h2> |
| | 1436 | <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body |
| | 1437 | is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>. |
| | 1438 | </p> |
| | 1439 | <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET |
| | 1440 | </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p> |
| | 1441 | <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if the method does not define any use for a |
| | 1442 | message body. |
| | 1443 | </p> |
| | 1444 | <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response |
| | 1445 | status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero |
| | 1446 | length. |
| | 1447 | </p> |
| | 1448 | <div id="header.transfer-encoding"> |
| | 1449 | <div id="rfc.iref.t.4"></div> |
| | 1450 | <div id="rfc.iref.c.6"></div> |
| | 1451 | <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a href="#header.transfer-encoding">Transfer-Encoding</a></h3> |
| | 1452 | <p id="rfc.section.3.3.1.p.1">The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that |
| | 1453 | have been (or will be) applied to the payload body in order to form the message body. Transfer codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. |
| | 1454 | </p> |
| | 1455 | <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> |
| | 1456 | </pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport |
| | 1457 | of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is |
| | 1458 | primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only |
| | 1459 | applied for transport efficiency or security from those that are characteristics of the selected resource. |
| | 1460 | </p> |
| | 1461 | <p id="rfc.section.3.3.1.p.4">A recipient <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer |
| | 1462 | coding other than chunked is applied to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than |
| | 1463 | chunked is applied to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection. |
| | 1464 | </p> |
| | 1465 | <div id="rfc.figure.u.27"></div> |
| | 1466 | <p>For example,</p><pre class="text"> Transfer-Encoding: gzip, chunked |
| | 1467 | </pre><p>indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while |
| | 1468 | forming the message body. |
| | 1469 | </p> |
| | 1470 | <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response |
| | 1471 | chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding |
| | 1472 | changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. |
| | 1473 | </p> |
| | 1474 | <p id="rfc.section.3.3.1.p.7">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer |
| | 1475 | coding to the message body if the request had been an unconditional GET. This indication is not required, however, because |
| | 1476 | any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. |
| | 1477 | </p> |
| | 1478 | <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| | 1479 | </p> |
| | 1480 | <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will |
| | 1481 | not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge |
| | 1482 | might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). |
| | 1483 | </p> |
| | 1484 | <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a>. |
| | 1485 | </p> |
| | 1486 | </div> |
| | 1487 | <div id="header.content-length"> |
| | 1488 | <div id="rfc.iref.c.7"></div> |
| | 1489 | <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a href="#header.content-length">Content-Length</a></h3> |
| | 1490 | <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential |
| | 1491 | payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information |
| | 1492 | necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length |
| | 1493 | indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| | 1494 | </p> |
| | 1495 | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> |
| | 1496 | </pre><p id="rfc.section.3.3.2.p.3">An example is</p> |
| | 1497 | <div id="rfc.figure.u.29"></div><pre class="text"> Content-Length: 3495 |
| | 1498 | </pre><p id="rfc.section.3.3.2.p.5">A sender <em class="bcp14">MUST NOT</em> send a Content-Length header field in any message that contains a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. |
| | 1499 | </p> |
| | 1500 | <p id="rfc.section.3.3.2.p.6">A user agent <em class="bcp14">SHOULD</em> send a Content-Length in a request message when no <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> is sent and the request method defines a meaning for an enclosed payload body. For example, a Content-Length header field |
| | 1501 | is normally sent in a POST request even when the value is 0 (indicating an empty payload body). A user agent <em class="bcp14">SHOULD NOT</em> send a Content-Length header field when the request message does not contain a payload body and the method semantics do not |
| | 1502 | anticipate such a body. |
| | 1503 | </p> |
| | 1504 | <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent |
| | 1505 | in the payload body of a response if the same request had used the GET method. |
| | 1506 | </p> |
| | 1507 | <p id="rfc.section.3.3.2.p.8">A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent |
| | 1508 | in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request. |
| | 1509 | </p> |
| | 1510 | <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| | 1511 | </p> |
| | 1512 | <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This |
| | 1513 | will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse |
| | 1514 | the connection for additional requests. |
| | 1515 | </p> |
| | 1516 | <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of |
| | 1517 | a payload, a recipient <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section 9.3</a>). |
| | 1518 | </p> |
| | 1519 | <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, |
| | 1520 | or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length: |
| | 1521 | 42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, |
| | 1522 | 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 |
| | 1523 | that decimal value prior to determining the message body length or forwarding the message. |
| | 1524 | </p> |
| | 1525 | <div class="note" id="rfc.section.3.3.2.p.13"> |
| | 1526 | <p><b>Note:</b> HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional |
| | 1527 | field used only within the "message/external-body" media-type. |
| | 1528 | </p> |
| | 1529 | </div> |
| | 1530 | </div> |
| | 1531 | <div id="message.body.length"> |
| | 1532 | <div id="rfc.iref.c.8"></div> |
| | 1533 | <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a href="#message.body.length">Message Body Length</a></h3> |
| | 1534 | <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p> |
| | 1535 | <p id="rfc.section.3.3.3.p.2"></p> |
| | 1536 | <ol> |
| | 1537 | <li> |
| | 1538 | <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present |
| | 1539 | in the message, and thus cannot contain a message body. |
| | 1540 | </p> |
| | 1541 | </li> |
| | 1542 | <li> |
| | 1543 | <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes |
| | 1544 | the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message. |
| | 1545 | </p> |
| | 1546 | </li> |
| | 1547 | <li> |
| | 1548 | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer |
| | 1549 | coding indicates the data is complete. |
| | 1550 | </p> |
| | 1551 | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is |
| | 1552 | determined by reading the connection until it is closed by the server. If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot |
| | 1553 | be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. |
| | 1554 | </p> |
| | 1555 | <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request |
| | 1556 | or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an |
| | 1557 | error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream. |
| | 1558 | </p> |
| | 1559 | </li> |
| | 1560 | <li> |
| | 1561 | <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message |
| | 1562 | framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response. |
| | 1563 | </p> |
| | 1564 | </li> |
| | 1565 | <li> |
| | 1566 | <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient |
| | 1567 | times out before the indicated number of octets are received, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and close the connection. |
| | 1568 | </p> |
| | 1569 | </li> |
| | 1570 | <li> |
| | 1571 | <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> |
| | 1572 | </li> |
| | 1573 | <li> |
| | 1574 | <p>Otherwise, this is a response message without a declared message body length, so the message body length is determined by |
| | 1575 | the number of octets received prior to the server closing the connection. |
| | 1576 | </p> |
| | 1577 | </li> |
| | 1578 | </ol> |
| | 1579 | <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted |
| | 1580 | by network failure, a server <em class="bcp14">SHOULD</em> generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards |
| | 1581 | compatibility with HTTP/1.0. |
| | 1582 | </p> |
| | 1583 | <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>. |
| | 1584 | </p> |
| | 1585 | <p id="rfc.section.3.3.3.p.5">Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing |
| | 1586 | services respond to chunked with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked transfer coding. This is typically because such services are implemented |
| | 1587 | via a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the |
| | 1588 | entire request before processing. |
| | 1589 | </p> |
| | 1590 | <p id="rfc.section.3.3.3.p.6">A user agent that sends a request containing a message body <em class="bcp14">MUST</em> send a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of |
| | 1591 | specific user configuration or by remembering the version of a prior received response. |
| | 1592 | </p> |
| | 1593 | <p id="rfc.section.3.3.3.p.7">If the final response to the last request on a connection has been completely received and there remains additional data to |
| | 1594 | read, a user agent <em class="bcp14">MAY</em> discard the remaining data or attempt to determine if that data belongs as part of the prior response body, which might be |
| | 1595 | the case if the prior message's Content-Length value is incorrect. A client <em class="bcp14">MUST NOT</em> process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning. |
| | 1596 | </p> |
| | 1597 | </div> |
| | 1598 | </div> |
| | 1599 | <div id="incomplete.messages"> |
| | 1600 | <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a href="#incomplete.messages">Handling Incomplete Messages</a></h2> |
| | 1601 | <p id="rfc.section.3.4.p.1">A server that receives an incomplete request message, usually due to a canceled request or a triggered time-out exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection. |
| | 1602 | </p> |
| | 1603 | <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding |
| | 1604 | a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. |
| | 1605 | </p> |
| | 1606 | <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might |
| | 1607 | rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed; |
| | 1608 | the client might need to repeat the request in order to determine what action to take next. |
| | 1609 | </p> |
| | 1610 | <p id="rfc.section.3.4.p.4">A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has |
| | 1611 | not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response |
| | 1612 | that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered |
| | 1613 | complete regardless of the number of message body octets received, provided that the header section was received intact. |
| | 1614 | </p> |
| | 1615 | </div> |
| | 1616 | <div id="message.robustness"> |
| | 1617 | <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a href="#message.robustness">Message Parsing Robustness</a></h2> |
| | 1618 | <p id="rfc.section.3.5.p.1">Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server |
| | 1619 | applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent <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 |
| | 1620 | the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length. |
| | 1621 | </p> |
| | 1622 | <p id="rfc.section.3.5.p.2">In the interest of robustness, a server that is expecting to receive and parse a request-line <em class="bcp14">SHOULD</em> ignore at least one empty line (CRLF) received prior to the request-line. |
| | 1623 | </p> |
| | 1624 | <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR. |
| | 1625 | </p> |
| | 1626 | <p id="rfc.section.3.5.p.4">Although the request-line and status-line grammar rules require that each of the component elements be separated by a single |
| | 1627 | SP octet, recipients <em class="bcp14">MAY</em> instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator, treat any form of whitespace as |
| | 1628 | the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets: |
| | 1629 | SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. |
| | 1630 | </p> |
| | 1631 | <p id="rfc.section.3.5.p.5">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request |
| | 1632 | message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed |
| | 1633 | above, the server <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response. |
| | 1634 | </p> |
| | 1635 | </div> |
| 1378 | | <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.53"></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> ) |
| 1379 | | </pre><p id="rfc.section.3.2.6.p.13">A sender <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 |
| 1380 | | ")"). |
| 1381 | | </p> |
| 1382 | | <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> |
| 1383 | | <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body |
| 1384 | | is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>. |
| 1385 | | </p> |
| 1386 | | <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET |
| 1387 | | </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p> |
| 1388 | | <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if the method does not define any use for a |
| 1389 | | message body. |
| 1390 | | </p> |
| 1391 | | <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response |
| 1392 | | status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero |
| 1393 | | length. |
| 1394 | | </p> |
| 1395 | | <div id="rfc.iref.t.4"></div> |
| 1396 | | <div id="rfc.iref.c.6"></div> |
| 1397 | | <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3> |
| 1398 | | <p id="rfc.section.3.3.1.p.1">The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that |
| 1399 | | have been (or will be) applied to the payload body in order to form the message body. Transfer codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. |
| 1400 | | </p> |
| 1401 | | <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> |
| 1402 | | </pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport |
| 1403 | | of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is |
| 1404 | | primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only |
| 1405 | | applied for transport efficiency or security from those that are characteristics of the selected resource. |
| 1406 | | </p> |
| 1407 | | <p id="rfc.section.3.3.1.p.4">A recipient <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer |
| 1408 | | coding other than chunked is applied to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than |
| 1409 | | chunked is applied to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection. |
| 1410 | | </p> |
| 1411 | | <div id="rfc.figure.u.27"></div> |
| 1412 | | <p>For example,</p><pre class="text"> Transfer-Encoding: gzip, chunked |
| 1413 | | </pre><p>indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while |
| 1414 | | forming the message body. |
| 1415 | | </p> |
| 1416 | | <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response |
| 1417 | | chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding |
| 1418 | | changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. |
| 1419 | | </p> |
| 1420 | | <p id="rfc.section.3.3.1.p.7">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer |
| 1421 | | coding to the message body if the request had been an unconditional GET. This indication is not required, however, because |
| 1422 | | any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. |
| 1423 | | </p> |
| 1424 | | <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| 1425 | | </p> |
| 1426 | | <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will |
| 1427 | | not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge |
| 1428 | | might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). |
| 1429 | | </p> |
| 1430 | | <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a>. |
| 1431 | | </p> |
| 1432 | | <div id="rfc.iref.c.7"></div> |
| 1433 | | <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h3> |
| 1434 | | <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential |
| 1435 | | payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information |
| 1436 | | necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length |
| 1437 | | indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| 1438 | | </p> |
| 1439 | | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> |
| 1440 | | </pre><p id="rfc.section.3.3.2.p.3">An example is</p> |
| 1441 | | <div id="rfc.figure.u.29"></div><pre class="text"> Content-Length: 3495 |
| 1442 | | </pre><p id="rfc.section.3.3.2.p.5">A sender <em class="bcp14">MUST NOT</em> send a Content-Length header field in any message that contains a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. |
| 1443 | | </p> |
| 1444 | | <p id="rfc.section.3.3.2.p.6">A user agent <em class="bcp14">SHOULD</em> send a Content-Length in a request message when no <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> is sent and the request method defines a meaning for an enclosed payload body. For example, a Content-Length header field |
| 1445 | | is normally sent in a POST request even when the value is 0 (indicating an empty payload body). A user agent <em class="bcp14">SHOULD NOT</em> send a Content-Length header field when the request message does not contain a payload body and the method semantics do not |
| 1446 | | anticipate such a body. |
| 1447 | | </p> |
| 1448 | | <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent |
| 1449 | | in the payload body of a response if the same request had used the GET method. |
| 1450 | | </p> |
| 1451 | | <p id="rfc.section.3.3.2.p.8">A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent |
| 1452 | | in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request. |
| 1453 | | </p> |
| 1454 | | <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| 1455 | | </p> |
| 1456 | | <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This |
| 1457 | | will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse |
| 1458 | | the connection for additional requests. |
| 1459 | | </p> |
| 1460 | | <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of |
| 1461 | | a payload, a recipient <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section 9.3</a>). |
| 1462 | | </p> |
| 1463 | | <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, |
| 1464 | | or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length: |
| 1465 | | 42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, |
| 1466 | | 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 |
| 1467 | | that decimal value prior to determining the message body length or forwarding the message. |
| 1468 | | </p> |
| 1469 | | <div class="note" id="rfc.section.3.3.2.p.13"> |
| 1470 | | <p><b>Note:</b> HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional |
| 1471 | | field used only within the "message/external-body" media-type. |
| 1472 | | </p> |
| 1473 | | </div> |
| 1474 | | <div id="rfc.iref.c.8"></div> |
| 1475 | | <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="message.body.length" href="#message.body.length">Message Body Length</a></h3> |
| 1476 | | <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p> |
| 1477 | | <p id="rfc.section.3.3.3.p.2"></p> |
| 1478 | | <ol> |
| 1479 | | <li> |
| 1480 | | <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present |
| 1481 | | in the message, and thus cannot contain a message body. |
| 1482 | | </p> |
| 1483 | | </li> |
| 1484 | | <li> |
| 1485 | | <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes |
| 1486 | | the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message. |
| 1487 | | </p> |
| 1488 | | </li> |
| 1489 | | <li> |
| 1490 | | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer |
| 1491 | | coding indicates the data is complete. |
| 1492 | | </p> |
| 1493 | | <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is |
| 1494 | | determined by reading the connection until it is closed by the server. If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot |
| 1495 | | be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. |
| 1496 | | </p> |
| 1497 | | <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request |
| 1498 | | or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an |
| 1499 | | error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream. |
| 1500 | | </p> |
| 1501 | | </li> |
| 1502 | | <li> |
| 1503 | | <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message |
| 1504 | | framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response. |
| 1505 | | </p> |
| 1506 | | </li> |
| 1507 | | <li> |
| 1508 | | <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient |
| 1509 | | times out before the indicated number of octets are received, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and close the connection. |
| 1510 | | </p> |
| 1511 | | </li> |
| 1512 | | <li> |
| 1513 | | <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> |
| 1514 | | </li> |
| 1515 | | <li> |
| 1516 | | <p>Otherwise, this is a response message without a declared message body length, so the message body length is determined by |
| 1517 | | the number of octets received prior to the server closing the connection. |
| 1518 | | </p> |
| 1519 | | </li> |
| 1520 | | </ol> |
| 1521 | | <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted |
| 1522 | | by network failure, a server <em class="bcp14">SHOULD</em> generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards |
| 1523 | | compatibility with HTTP/1.0. |
| 1524 | | </p> |
| 1525 | | <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>. |
| 1526 | | </p> |
| 1527 | | <p id="rfc.section.3.3.3.p.5">Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing |
| 1528 | | services respond to chunked with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked transfer coding. This is typically because such services are implemented |
| 1529 | | via a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the |
| 1530 | | entire request before processing. |
| 1531 | | </p> |
| 1532 | | <p id="rfc.section.3.3.3.p.6">A user agent that sends a request containing a message body <em class="bcp14">MUST</em> send a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of |
| 1533 | | specific user configuration or by remembering the version of a prior received response. |
| 1534 | | </p> |
| 1535 | | <p id="rfc.section.3.3.3.p.7">If the final response to the last request on a connection has been completely received and there remains additional data to |
| 1536 | | read, a user agent <em class="bcp14">MAY</em> discard the remaining data or attempt to determine if that data belongs as part of the prior response body, which might be |
| 1537 | | the case if the prior message's Content-Length value is incorrect. A client <em class="bcp14">MUST NOT</em> process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning. |
| 1538 | | </p> |
| 1539 | | <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> |
| 1540 | | <p id="rfc.section.3.4.p.1">A server that receives an incomplete request message, usually due to a canceled request or a triggered time-out exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection. |
| 1541 | | </p> |
| 1542 | | <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding |
| 1543 | | a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. |
| 1544 | | </p> |
| 1545 | | <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might |
| 1546 | | rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed; |
| 1547 | | the client might need to repeat the request in order to determine what action to take next. |
| 1548 | | </p> |
| 1549 | | <p id="rfc.section.3.4.p.4">A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has |
| 1550 | | not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response |
| 1551 | | that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered |
| 1552 | | complete regardless of the number of message body octets received, provided that the header section was received intact. |
| 1553 | | </p> |
| 1554 | | <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> |
| 1555 | | <p id="rfc.section.3.5.p.1">Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server |
| 1556 | | applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent <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 |
| 1557 | | the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length. |
| 1558 | | </p> |
| 1559 | | <p id="rfc.section.3.5.p.2">In the interest of robustness, a server that is expecting to receive and parse a request-line <em class="bcp14">SHOULD</em> ignore at least one empty line (CRLF) received prior to the request-line. |
| 1560 | | </p> |
| 1561 | | <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR. |
| 1562 | | </p> |
| 1563 | | <p id="rfc.section.3.5.p.4">Although the request-line and status-line grammar rules require that each of the component elements be separated by a single |
| 1564 | | SP octet, recipients <em class="bcp14">MAY</em> instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator, treat any form of whitespace as |
| 1565 | | the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets: |
| 1566 | | SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. |
| 1567 | | </p> |
| 1568 | | <p id="rfc.section.3.5.p.5">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request |
| 1569 | | message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed |
| 1570 | | above, the server <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response. |
| 1571 | | </p> |
| 1572 | | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1> |
| 1573 | | <p id="rfc.section.4.p.1">Transfer coding names are used to indicate an encoding transformation that has been, can be, or might need to be applied to |
| 1574 | | a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer |
| 1575 | | coding is a property of the message rather than a property of the representation that is being transferred. |
| 1576 | | </p> |
| 1577 | | <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> |
| | 1637 | <div id="transfer.codings"> |
| | 1638 | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#transfer.codings">Transfer Codings</a></h1> |
| | 1639 | <p id="rfc.section.4.p.1">Transfer coding names are used to indicate an encoding transformation that has been, can be, or might need to be applied to |
| | 1640 | a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer |
| | 1641 | coding is a property of the message rather than a property of the representation that is being transferred. |
| | 1642 | </p> |
| | 1643 | <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> |
| 1716 | | coding, as defined in <a href="#chunked.trailer.part" title="Chunked Trailer Part">Section 4.1.2</a>, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that either: (a) all downstream |
| 1717 | | clients are willing to accept trailer fields in the forwarded response; or, (b) the intermediary will attempt to buffer the |
| 1718 | | response on behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response |
| 1719 | | such that an intermediary can be assured of buffering the entire response. |
| 1720 | | </p> |
| 1721 | | <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation |
| 1722 | | fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; |
| 1723 | | a value of 0 means "not acceptable". |
| 1724 | | </p> |
| 1725 | | <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer coding is chunked. A message with |
| 1726 | | no transfer coding is always acceptable. |
| 1727 | | </p> |
| 1728 | | <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics. |
| 1729 | | </p> |
| 1730 | | <div id="rfc.iref.t.6"></div> |
| 1731 | | <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> |
| 1732 | | <p id="rfc.section.4.4.p.1">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in |
| 1733 | | the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to |
| 1734 | | prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed |
| 1735 | | and the recipient wishes to confirm an integrity check on the fly. |
| 1736 | | </p> |
| 1737 | | <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.92"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> |
| 1738 | | </pre><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> |
| 1739 | | <p id="rfc.section.5.p.1">HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, |
| 1740 | | and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain |
| 1741 | | back to the client. |
| 1742 | | </p> |
| 1743 | | <div id="rfc.iref.t.7"></div> |
| 1744 | | <div id="rfc.iref.t.8"></div> |
| 1745 | | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="target-resource" href="#target-resource">Identifying a Target Resource</a></h2> |
| 1746 | | <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, |
| 1747 | | communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification |
| 1748 | | mechanism and configuration techniques as general-purpose Web browsers. |
| 1749 | | </p> |
| 1750 | | <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which |
| 1751 | | are defined in <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side |
| 1752 | | processing (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). |
| 1753 | | </p> |
| 1754 | | <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="connecting.inbound" href="#connecting.inbound">Connecting Inbound</a></h2> |
| 1755 | | <p id="rfc.section.5.2.p.1">Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired |
| 1756 | | semantics and, if so, where that request is to be directed. |
| 1757 | | </p> |
| 1758 | | <p id="rfc.section.5.2.p.2">If the client has a cache <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> and the request can be satisfied by it, then the request is usually directed there first. |
| 1759 | | </p> |
| 1760 | | <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy |
| 1761 | | is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, |
| 1762 | | selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy |
| 1763 | | is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. |
| 1764 | | </p> |
| 1765 | | <p id="rfc.section.5.2.p.4">If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to |
| 1766 | | connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and |
| 1767 | | defined by its associated specification, similar to how this specification defines origin server access for resolution of |
| 1768 | | the "http" (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) schemes. |
| 1769 | | </p> |
| 1770 | | <p id="rfc.section.5.2.p.5">HTTP requirements regarding connection management are defined in <a href="#connection.management" title="Connection Management">Section 6</a>. |
| 1771 | | </p> |
| 1772 | | <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="request-target" href="#request-target">Request Target</a></h2> |
| 1773 | | <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on |
| 1774 | | both the method being requested and whether the request is to a proxy. |
| 1775 | | </p> |
| 1776 | | <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a> |
| | 1799 | coding, as defined in <a href="#chunked.trailer.part" title="Chunked Trailer Part">Section 4.1.2</a>, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that either: (a) all downstream |
| | 1800 | clients are willing to accept trailer fields in the forwarded response; or, (b) the intermediary will attempt to buffer the |
| | 1801 | response on behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response |
| | 1802 | such that an intermediary can be assured of buffering the entire response. |
| | 1803 | </p> |
| | 1804 | <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation |
| | 1805 | fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; |
| | 1806 | a value of 0 means "not acceptable". |
| | 1807 | </p> |
| | 1808 | <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer coding is chunked. A message with |
| | 1809 | no transfer coding is always acceptable. |
| | 1810 | </p> |
| | 1811 | <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics. |
| | 1812 | </p> |
| | 1813 | </div> |
| | 1814 | <div id="header.trailer"> |
| | 1815 | <div id="rfc.iref.t.6"></div> |
| | 1816 | <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a href="#header.trailer">Trailer</a></h2> |
| | 1817 | <p id="rfc.section.4.4.p.1">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in |
| | 1818 | the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to |
| | 1819 | prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed |
| | 1820 | and the recipient wishes to confirm an integrity check on the fly. |
| | 1821 | </p> |
| | 1822 | <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.92"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> |
| | 1823 | </pre></div> |
| | 1824 | </div> |
| | 1825 | <div id="message.routing"> |
| | 1826 | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#message.routing">Message Routing</a></h1> |
| | 1827 | <p id="rfc.section.5.p.1">HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, |
| | 1828 | and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain |
| | 1829 | back to the client. |
| | 1830 | </p> |
| | 1831 | <div id="target-resource"> |
| | 1832 | <div id="rfc.iref.t.7"></div> |
| | 1833 | <div id="rfc.iref.t.8"></div> |
| | 1834 | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a href="#target-resource">Identifying a Target Resource</a></h2> |
| | 1835 | <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, |
| | 1836 | communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification |
| | 1837 | mechanism and configuration techniques as general-purpose Web browsers. |
| | 1838 | </p> |
| | 1839 | <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which |
| | 1840 | are defined in <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side |
| | 1841 | processing (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). |
| | 1842 | </p> |
| | 1843 | </div> |
| | 1844 | <div id="connecting.inbound"> |
| | 1845 | <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a href="#connecting.inbound">Connecting Inbound</a></h2> |
| | 1846 | <p id="rfc.section.5.2.p.1">Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired |
| | 1847 | semantics and, if so, where that request is to be directed. |
| | 1848 | </p> |
| | 1849 | <p id="rfc.section.5.2.p.2">If the client has a cache <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> and the request can be satisfied by it, then the request is usually directed there first. |
| | 1850 | </p> |
| | 1851 | <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy |
| | 1852 | is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, |
| | 1853 | selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy |
| | 1854 | is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. |
| | 1855 | </p> |
| | 1856 | <p id="rfc.section.5.2.p.4">If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to |
| | 1857 | connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and |
| | 1858 | defined by its associated specification, similar to how this specification defines origin server access for resolution of |
| | 1859 | the "http" (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) schemes. |
| | 1860 | </p> |
| | 1861 | <p id="rfc.section.5.2.p.5">HTTP requirements regarding connection management are defined in <a href="#connection.management" title="Connection Management">Section 6</a>. |
| | 1862 | </p> |
| | 1863 | </div> |
| | 1864 | <div id="request-target"> |
| | 1865 | <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a href="#request-target">Request Target</a></h2> |
| | 1866 | <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on |
| | 1867 | both the method being requested and whether the request is to a proxy. |
| | 1868 | </p> |
| | 1869 | <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a> |
| 1852 | | Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. |
| 1853 | | </p> |
| 1854 | | <p id="rfc.section.5.4.p.8">When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy |
| 1855 | | that forwards such a request <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value. |
| 1856 | | </p> |
| 1857 | | <p id="rfc.section.5.4.p.9">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to |
| 1858 | | poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it |
| 1859 | | relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache, |
| 1860 | | without first verifying that the intercepted connection is targeting a valid IP address for that host. |
| 1861 | | </p> |
| 1862 | | <p id="rfc.section.5.4.p.10">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than |
| 1863 | | one Host header field or a Host header field with an invalid field-value. |
| 1864 | | </p> |
| 1865 | | <div id="rfc.iref.e.1"></div> |
| 1866 | | <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> |
| 1867 | | <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request. |
| 1868 | | The URI derived from this reconstruction process is referred to as the "<dfn>effective request URI</dfn>". |
| 1869 | | </p> |
| 1870 | | <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p> |
| 1871 | | <p id="rfc.section.5.5.p.3">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the |
| 1872 | | effective request URI is constructed as follows. |
| 1873 | | </p> |
| 1874 | | <p id="rfc.section.5.5.p.4">If the request is received over a TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise, |
| 1875 | | the scheme is "http". |
| 1876 | | </p> |
| 1877 | | <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target. |
| 1878 | | Otherwise, if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, then the authority component is the same as the Host field-value. Otherwise, |
| 1879 | | the authority component is the concatenation of the default host name configured for the server, a colon (":"), and the connection's |
| 1880 | | incoming TCP port number in decimal form. |
| 1881 | | </p> |
| 1882 | | <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component |
| 1883 | | is empty. Otherwise, the combined path and query component is the same as the request-target. |
| 1884 | | </p> |
| 1885 | | <p id="rfc.section.5.5.p.7">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating |
| 1886 | | the scheme, "://", authority, and combined path and query component. |
| 1887 | | </p> |
| 1888 | | <div id="rfc.figure.u.49"></div> |
| 1889 | | <p>Example 1: the following message received over an insecure TCP connection</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 |
| | 1947 | Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. |
| | 1948 | </p> |
| | 1949 | <p id="rfc.section.5.4.p.8">When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy |
| | 1950 | that forwards such a request <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value. |
| | 1951 | </p> |
| | 1952 | <p id="rfc.section.5.4.p.9">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to |
| | 1953 | poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it |
| | 1954 | relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache, |
| | 1955 | without first verifying that the intercepted connection is targeting a valid IP address for that host. |
| | 1956 | </p> |
| | 1957 | <p id="rfc.section.5.4.p.10">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than |
| | 1958 | one Host header field or a Host header field with an invalid field-value. |
| | 1959 | </p> |
| | 1960 | </div> |
| | 1961 | <div id="effective.request.uri"> |
| | 1962 | <div id="rfc.iref.e.1"></div> |
| | 1963 | <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a href="#effective.request.uri">Effective Request URI</a></h2> |
| | 1964 | <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request. |
| | 1965 | The URI derived from this reconstruction process is referred to as the "<dfn>effective request URI</dfn>". |
| | 1966 | </p> |
| | 1967 | <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p> |
| | 1968 | <p id="rfc.section.5.5.p.3">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the |
| | 1969 | effective request URI is constructed as follows. |
| | 1970 | </p> |
| | 1971 | <p id="rfc.section.5.5.p.4">If the request is received over a TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise, |
| | 1972 | the scheme is "http". |
| | 1973 | </p> |
| | 1974 | <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target. |
| | 1975 | Otherwise, if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, then the authority component is the same as the Host field-value. Otherwise, |
| | 1976 | the authority component is the concatenation of the default host name configured for the server, a colon (":"), and the connection's |
| | 1977 | incoming TCP port number in decimal form. |
| | 1978 | </p> |
| | 1979 | <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component |
| | 1980 | is empty. Otherwise, the combined path and query component is the same as the request-target. |
| | 1981 | </p> |
| | 1982 | <p id="rfc.section.5.5.p.7">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating |
| | 1983 | the scheme, "://", authority, and combined path and query component. |
| | 1984 | </p> |
| | 1985 | <div id="rfc.figure.u.49"></div> |
| | 1986 | <p>Example 1: the following message received over an insecure TCP connection</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 |
| 1899 | | </p> |
| 1900 | | <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess |
| 1901 | | the effective request URI's authority component. |
| 1902 | | </p> |
| 1903 | | <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> |
| 1904 | | <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response |
| 1905 | | messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made |
| 1906 | | on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request. |
| 1907 | | </p> |
| 1908 | | <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final |
| 1909 | | (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. |
| 1910 | | </p> |
| 1911 | | <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2> |
| 1912 | | <p id="rfc.section.5.7.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section 2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used |
| 1913 | | to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has |
| 1914 | | characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can |
| 1915 | | enhance (or interfere) with either direction of the stream. |
| 1916 | | </p> |
| 1917 | | <p id="rfc.section.5.7.p.2">An intermediary not acting as a tunnel <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>, and exclude fields from being forwarded that are only intended for the incoming connection. |
| 1918 | | </p> |
| 1919 | | <p id="rfc.section.5.7.p.3">An intermediary <em class="bcp14">MUST NOT</em> forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize |
| 1920 | | its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly. |
| 1921 | | </p> |
| 1922 | | <div id="rfc.iref.v.1"></div> |
| 1923 | | <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a> <a id="header.via" href="#header.via">Via</a></h3> |
| 1924 | | <p id="rfc.section.5.7.1.p.1">The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server |
| 1925 | | (on requests) or between the origin server and the client (on responses), similar to the "Received" header field in email |
| 1926 | | (<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>). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders |
| 1927 | | along the request/response chain. |
| 1928 | | </p> |
| 1929 | | <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></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> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) |
| | 1996 | </p> |
| | 1997 | <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess |
| | 1998 | the effective request URI's authority component. |
| | 1999 | </p> |
| | 2000 | </div> |
| | 2001 | <div id="associating.response.to.request"> |
| | 2002 | <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a href="#associating.response.to.request">Associating a Response to a Request</a></h2> |
| | 2003 | <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response |
| | 2004 | messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made |
| | 2005 | on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request. |
| | 2006 | </p> |
| | 2007 | <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final |
| | 2008 | (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. |
| | 2009 | </p> |
| | 2010 | </div> |
| | 2011 | <div id="message.forwarding"> |
| | 2012 | <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a href="#message.forwarding">Message Forwarding</a></h2> |
| | 2013 | <p id="rfc.section.5.7.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section 2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used |
| | 2014 | to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has |
| | 2015 | characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can |
| | 2016 | enhance (or interfere) with either direction of the stream. |
| | 2017 | </p> |
| | 2018 | <p id="rfc.section.5.7.p.2">An intermediary not acting as a tunnel <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>, and exclude fields from being forwarded that are only intended for the incoming connection. |
| | 2019 | </p> |
| | 2020 | <p id="rfc.section.5.7.p.3">An intermediary <em class="bcp14">MUST NOT</em> forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize |
| | 2021 | its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly. |
| | 2022 | </p> |
| | 2023 | <div id="header.via"> |
| | 2024 | <div id="rfc.iref.v.1"></div> |
| | 2025 | <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a> <a href="#header.via">Via</a></h3> |
| | 2026 | <p id="rfc.section.5.7.1.p.1">The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server |
| | 2027 | (on requests) or between the origin server and the client (on responses), similar to the "Received" header field in email |
| | 2028 | (<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>). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders |
| | 2029 | along the request/response chain. |
| | 2030 | </p> |
| | 2031 | <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></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> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) |
| 1966 | | by pseudonyms. A sender <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values. |
| 1967 | | </p> |
| 1968 | | <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a> <a id="message.transformations" href="#message.transformations">Transformations</a></h3> |
| 1969 | | <p id="rfc.section.5.7.2.p.1">Some intermediaries include features for transforming messages and their payloads. A transforming proxy might, for example, |
| 1970 | | convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational |
| 1971 | | problems might occur when these transformations are applied to payloads intended for critical applications, such as medical |
| 1972 | | imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the |
| 1973 | | payload received is identical to the original. |
| 1974 | | </p> |
| 1975 | | <p id="rfc.section.5.7.2.p.2">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. |
| 1976 | | </p> |
| 1977 | | <p id="rfc.section.5.7.2.p.3">A proxy <em class="bcp14">MUST NOT</em> modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server, |
| 1978 | | except as noted above to replace an empty path with "/" or "*". |
| 1979 | | </p> |
| 1980 | | <p id="rfc.section.5.7.2.p.4">A proxy <em class="bcp14">MUST NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the |
| 1981 | | selected representation. A proxy <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). |
| 1982 | | </p> |
| 1983 | | <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A transforming proxy <em class="bcp14">MUST NOT</em> modify the payload of a message that contains the no-transform cache-control directive. |
| 1984 | | </p> |
| 1985 | | <p id="rfc.section.5.7.2.p.6">A transforming proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed, |
| 1986 | | the transforming proxy <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one does not already appear in the message |
| 1987 | | (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response is transformed, the transforming proxy can also inform downstream recipients that a transformation has been applied |
| 1988 | | by changing the response status code to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| 1989 | | </p> |
| 1990 | | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connection.management" href="#connection.management">Connection Management</a></h1> |
| 1991 | | <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable |
| 1992 | | transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request |
| 1993 | | and response structures onto the data units of an underlying transport protocol is outside the scope of this specification. |
| 1994 | | </p> |
| 1995 | | <p id="rfc.section.6.p.2">As described in <a href="#connecting.inbound" title="Connecting Inbound">Section 5.2</a>, the specific connection protocols to be used for an HTTP interaction are determined by client configuration and the <a href="#target-resource" class="smpl">target URI</a>. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use |
| 1996 | | a proxy via some other connection, port, or protocol. |
| 1997 | | </p> |
| 1998 | | <p id="rfc.section.6.p.3">HTTP implementations are expected to engage in connection management, which includes maintaining the state of current connections, |
| 1999 | | establishing a new connection or reusing an existing connection, processing messages received on a connection, detecting connection |
| 2000 | | failures, and closing each connection. Most clients maintain multiple connections in parallel, including more than one connection |
| 2001 | | per server endpoint. Most servers are designed to maintain thousands of concurrent connections, while controlling request |
| 2002 | | queues to enable fair use and detect denial of service attacks. |
| 2003 | | </p> |
| 2004 | | <div id="rfc.iref.c.11"></div> |
| 2005 | | <div id="rfc.iref.c.12"></div> |
| 2006 | | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> |
| 2007 | | <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to |
| 2008 | | avoid confusing downstream recipients, a proxy or gateway <em class="bcp14">MUST</em> remove or replace any received connection options before forwarding the message. |
| 2009 | | </p> |
| 2010 | | <p id="rfc.section.6.1.p.2">When a header field aside from Connection is used to supply control information for or about the current connection, the sender <em class="bcp14">MUST</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove |
| 2011 | | any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field |
| 2012 | | itself (or replace it with the intermediary's own connection options for the forwarded message). |
| 2013 | | </p> |
| 2014 | | <p id="rfc.section.6.1.p.3">Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the |
| 2015 | | immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling |
| 2016 | | the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they |
| 2017 | | will be blindly forwarded by older intermediaries. |
| 2018 | | </p> |
| 2019 | | <p id="rfc.section.6.1.p.4">The Connection header field's value has the following grammar:</p> |
| 2020 | | <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> |
| | 2068 | by pseudonyms. A sender <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values. |
| | 2069 | </p> |
| | 2070 | </div> |
| | 2071 | <div id="message.transformations"> |
| | 2072 | <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a> <a href="#message.transformations">Transformations</a></h3> |
| | 2073 | <p id="rfc.section.5.7.2.p.1">Some intermediaries include features for transforming messages and their payloads. A transforming proxy might, for example, |
| | 2074 | convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational |
| | 2075 | problems might occur when these transformations are applied to payloads intended for critical applications, such as medical |
| | 2076 | imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the |
| | 2077 | payload received is identical to the original. |
| | 2078 | </p> |
| | 2079 | <p id="rfc.section.5.7.2.p.2">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. |
| | 2080 | </p> |
| | 2081 | <p id="rfc.section.5.7.2.p.3">A proxy <em class="bcp14">MUST NOT</em> modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server, |
| | 2082 | except as noted above to replace an empty path with "/" or "*". |
| | 2083 | </p> |
| | 2084 | <p id="rfc.section.5.7.2.p.4">A proxy <em class="bcp14">MUST NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the |
| | 2085 | selected representation. A proxy <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). |
| | 2086 | </p> |
| | 2087 | <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A transforming proxy <em class="bcp14">MUST NOT</em> modify the payload of a message that contains the no-transform cache-control directive. |
| | 2088 | </p> |
| | 2089 | <p id="rfc.section.5.7.2.p.6">A transforming proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed, |
| | 2090 | the transforming proxy <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one does not already appear in the message |
| | 2091 | (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response is transformed, the transforming proxy can also inform downstream recipients that a transformation has been applied |
| | 2092 | by changing the response status code to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). |
| | 2093 | </p> |
| | 2094 | </div> |
| | 2095 | </div> |
| | 2096 | </div> |
| | 2097 | <div id="connection.management"> |
| | 2098 | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#connection.management">Connection Management</a></h1> |
| | 2099 | <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable |
| | 2100 | transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request |
| | 2101 | and response structures onto the data units of an underlying transport protocol is outside the scope of this specification. |
| | 2102 | </p> |
| | 2103 | <p id="rfc.section.6.p.2">As described in <a href="#connecting.inbound" title="Connecting Inbound">Section 5.2</a>, the specific connection protocols to be used for an HTTP interaction are determined by client configuration and the <a href="#target-resource" class="smpl">target URI</a>. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use |
| | 2104 | a proxy via some other connection, port, or protocol. |
| | 2105 | </p> |
| | 2106 | <p id="rfc.section.6.p.3">HTTP implementations are expected to engage in connection management, which includes maintaining the state of current connections, |
| | 2107 | establishing a new connection or reusing an existing connection, processing messages received on a connection, detecting connection |
| | 2108 | failures, and closing each connection. Most clients maintain multiple connections in parallel, including more than one connection |
| | 2109 | per server endpoint. Most servers are designed to maintain thousands of concurrent connections, while controlling request |
| | 2110 | queues to enable fair use and detect denial of service attacks. |
| | 2111 | </p> |
| | 2112 | <div id="header.connection"> |
| | 2113 | <div id="rfc.iref.c.11"></div> |
| | 2114 | <div id="rfc.iref.c.12"></div> |
| | 2115 | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a href="#header.connection">Connection</a></h2> |
| | 2116 | <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to |
| | 2117 | avoid confusing downstream recipients, a proxy or gateway <em class="bcp14">MUST</em> remove or replace any received connection options before forwarding the message. |
| | 2118 | </p> |
| | 2119 | <p id="rfc.section.6.1.p.2">When a header field aside from Connection is used to supply control information for or about the current connection, the sender <em class="bcp14">MUST</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove |
| | 2120 | any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field |
| | 2121 | itself (or replace it with the intermediary's own connection options for the forwarded message). |
| | 2122 | </p> |
| | 2123 | <p id="rfc.section.6.1.p.3">Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the |
| | 2124 | immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling |
| | 2125 | the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they |
| | 2126 | will be blindly forwarded by older intermediaries. |
| | 2127 | </p> |
| | 2128 | <p id="rfc.section.6.1.p.4">The Connection header field's value has the following grammar:</p> |
| | 2129 | <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> |
| 2042 | | request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.6</a>). |
| 2043 | | </p> |
| 2044 | | <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every request message. |
| 2045 | | </p> |
| 2046 | | <p id="rfc.section.6.1.p.14">A server that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code. |
| 2047 | | </p> |
| 2048 | | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="persistent.establishment" href="#persistent.establishment">Establishment</a></h2> |
| 2049 | | <p id="rfc.section.6.2.p.1">It is beyond the scope of this specification to describe how connections are established via various transport or session-layer |
| 2050 | | protocols. Each connection applies to only one transport link. |
| 2051 | | </p> |
| 2052 | | <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="persistent.connections" href="#persistent.connections">Persistence</a></h2> |
| 2053 | | <p id="rfc.section.6.3.p.1">HTTP/1.1 defaults to the use of "<dfn>persistent connections</dfn>", allowing multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will not persist after the current request/response. HTTP implementations <em class="bcp14">SHOULD</em> support persistent connections. |
| 2054 | | </p> |
| 2055 | | <p id="rfc.section.6.3.p.2">A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version |
| 2056 | | and <a href="#header.connection" class="smpl">Connection</a> header field (if any): |
| 2057 | | </p> |
| 2058 | | <ul> |
| 2059 | | <li>If the <a href="#header.connection" class="smpl">close</a> connection option is present, the connection will not persist after the current response; else, |
| 2060 | | </li> |
| 2061 | | <li>If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,</li> |
| 2062 | | <li>If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, and the |
| 2063 | | recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise, |
| 2064 | | </li> |
| 2065 | | <li>The connection will close after the current response.</li> |
| 2066 | | </ul> |
| 2067 | | <p id="rfc.section.6.3.p.3">A server <em class="bcp14">MAY</em> assume that an HTTP/1.1 client intends to maintain a persistent connection until a <a href="#header.connection" class="smpl">close</a> connection option is received in a request. |
| 2068 | | </p> |
| 2069 | | <p id="rfc.section.6.3.p.4">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option. |
| 2070 | | </p> |
| 2071 | | <p id="rfc.section.6.3.p.5">In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined |
| 2072 | | by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 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 |
| 2073 | | 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. |
| 2074 | | </p> |
| 2075 | | <p id="rfc.section.6.3.p.6">A proxy server <em class="bcp14">MUST NOT</em> maintain a persistent connection with an HTTP/1.0 client (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). |
| 2076 | | </p> |
| 2077 | | <p id="rfc.section.6.3.p.7">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. |
| 2078 | | </p> |
| 2079 | | <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> |
| 2080 | | <p id="rfc.section.6.3.1.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover |
| 2081 | | from asynchronous close events. |
| 2082 | | </p> |
| 2083 | | <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent |
| 2084 | | methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests. |
| 2085 | | </p> |
| 2086 | | <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are |
| 2087 | | actually idempotent, regardless of the method, or some means to detect that the original request was never applied. For example, |
| 2088 | | a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that |
| 2089 | | request automatically. Likewise, a user agent designed specifically to operate on a version control repository might be able |
| 2090 | | to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting |
| 2091 | | or fixing any changes that were partially applied, and then automatically retrying the requests that failed. |
| 2092 | | </p> |
| 2093 | | <p id="rfc.section.6.3.1.p.4">A client <em class="bcp14">SHOULD NOT</em> automatically retry a failed automatic retry. |
| 2094 | | </p> |
| 2095 | | <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h3> |
| 2096 | | <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received. |
| 2097 | | </p> |
| 2098 | | <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined |
| 2099 | | requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client <em class="bcp14">MUST NOT</em> pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused |
| 2100 | | an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset |
| 2101 | | problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section 6.6</a>). |
| 2102 | | </p> |
| 2103 | | <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless |
| 2104 | | the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence. |
| 2105 | | </p> |
| 2106 | | <p id="rfc.section.6.3.2.p.4">An intermediary that receives pipelined requests <em class="bcp14">MAY</em> pipeline those requests when forwarding them inbound, since it can rely on the outbound user agent(s) to determine what requests |
| 2107 | | can be safely pipelined. If the inbound connection fails before receiving a response, the pipelining intermediary <em class="bcp14">MAY</em> attempt to retry a sequence of requests that have yet to receive a response if the requests all have idempotent methods; otherwise, |
| 2108 | | the pipelining intermediary <em class="bcp14">SHOULD</em> forward any received responses and then close the corresponding outbound connection(s) so that the outbound user agent(s) |
| 2109 | | can recover accordingly. |
| 2110 | | </p> |
| 2111 | | <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h2> |
| 2112 | | <p id="rfc.section.6.4.p.1">A client <em class="bcp14">SHOULD</em> limit the number of simultaneous open connections that it maintains to a given server. |
| 2113 | | </p> |
| 2114 | | <p id="rfc.section.6.4.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many |
| 2115 | | applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages |
| 2116 | | clients to be conservative when opening multiple connections. |
| 2117 | | </p> |
| 2118 | | <p id="rfc.section.6.4.p.3">Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant |
| 2119 | | server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection |
| 2120 | | consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks. |
| 2121 | | </p> |
| 2122 | | <p id="rfc.section.6.4.p.4">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> |
| 2123 | | <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="persistent.failures" href="#persistent.failures">Failures and Time-outs</a></h2> |
| 2124 | | <p id="rfc.section.6.5.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers |
| 2125 | | might make this a higher value since it is likely that the client will be making more connections through the same server. |
| 2126 | | The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client |
| 2127 | | or the server. |
| 2128 | | </p> |
| 2129 | | <p id="rfc.section.6.5.p.2">A client or server that wishes to time-out <em class="bcp14">SHOULD</em> issue a graceful close on the connection. Implementations <em class="bcp14">SHOULD</em> constantly monitor open connections for a received closure signal and respond to it as appropriate, since prompt closure of |
| 2130 | | both sides of a connection enables allocated system resources to be reclaimed. |
| 2131 | | </p> |
| 2132 | | <p id="rfc.section.6.5.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 |
| 2133 | | that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed |
| 2134 | | while it was idle, but from the client's point of view, a request is in progress. |
| 2135 | | </p> |
| 2136 | | <p id="rfc.section.6.5.p.4">A server <em class="bcp14">SHOULD</em> sustain persistent connections, when possible, and allow the underlying transport's flow control mechanisms to resolve temporary |
| 2137 | | overloads, rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate |
| 2138 | | network congestion. |
| 2139 | | </p> |
| 2140 | | <p id="rfc.section.6.5.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error response while it is transmitting the request. If the client sees a response that |
| 2141 | | indicates the server does not wish to receive the message body and is closing the connection, the client <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close its side of the connection. |
| 2142 | | </p> |
| 2143 | | <div id="rfc.iref.c.13"></div> |
| 2144 | | <div id="rfc.iref.c.14"></div> |
| 2145 | | <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h2> |
| 2146 | | <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair. |
| 2147 | | </p> |
| 2148 | | <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. |
| 2149 | | </p> |
| 2150 | | <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> send a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. |
| 2151 | | </p> |
| 2152 | | <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. |
| 2153 | | </p> |
| 2154 | | <p id="rfc.section.6.6.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close; |
| 2155 | | if additional pipelined requests had been sent on the connection, the client <em class="bcp14">SHOULD NOT</em> assume that they will be processed by the server. |
| 2156 | | </p> |
| 2157 | | <p id="rfc.section.6.6.p.6">If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able |
| 2158 | | to read the last HTTP response. If the server receives additional data from the client on a fully-closed connection, such |
| 2159 | | as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a |
| 2160 | | reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they |
| 2161 | | can be read and interpreted by the client's HTTP parser. |
| 2162 | | </p> |
| 2163 | | <p id="rfc.section.6.6.p.7">To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by |
| 2164 | | closing only the write side of the read/write connection. The server then continues to read from the connection until it receives |
| 2165 | | a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's |
| 2166 | | acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection. |
| 2167 | | </p> |
| 2168 | | <p id="rfc.section.6.6.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p> |
| 2169 | | <div id="rfc.iref.u.5"></div> |
| 2170 | | <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> |
| 2171 | | <p id="rfc.section.6.7.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol |
| 2172 | | on the same connection. A client <em class="bcp14">MAY</em> send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols, |
| 2173 | | in order of descending preference, before sending the final response. A server <em class="bcp14">MAY</em> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. |
| 2174 | | </p> |
| 2175 | | <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.107"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> |
| | 2151 | request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.6</a>). |
| | 2152 | </p> |
| | 2153 | <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every request message. |
| | 2154 | </p> |
| | 2155 | <p id="rfc.section.6.1.p.14">A server that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code. |
| | 2156 | </p> |
| | 2157 | </div> |
| | 2158 | <div id="persistent.establishment"> |
| | 2159 | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a href="#persistent.establishment">Establishment</a></h2> |
| | 2160 | <p id="rfc.section.6.2.p.1">It is beyond the scope of this specification to describe how connections are established via various transport or session-layer |
| | 2161 | protocols. Each connection applies to only one transport link. |
| | 2162 | </p> |
| | 2163 | </div> |
| | 2164 | <div id="persistent.connections"> |
| | 2165 | <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a href="#persistent.connections">Persistence</a></h2> |
| | 2166 | <p id="rfc.section.6.3.p.1">HTTP/1.1 defaults to the use of "<dfn>persistent connections</dfn>", allowing multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will not persist after the current request/response. HTTP implementations <em class="bcp14">SHOULD</em> support persistent connections. |
| | 2167 | </p> |
| | 2168 | <p id="rfc.section.6.3.p.2">A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version |
| | 2169 | and <a href="#header.connection" class="smpl">Connection</a> header field (if any): |
| | 2170 | </p> |
| | 2171 | <ul> |
| | 2172 | <li>If the <a href="#header.connection" class="smpl">close</a> connection option is present, the connection will not persist after the current response; else, |
| | 2173 | </li> |
| | 2174 | <li>If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,</li> |
| | 2175 | <li>If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, and the |
| | 2176 | recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise, |
| | 2177 | </li> |
| | 2178 | <li>The connection will close after the current response.</li> |
| | 2179 | </ul> |
| | 2180 | <p id="rfc.section.6.3.p.3">A server <em class="bcp14">MAY</em> assume that an HTTP/1.1 client intends to maintain a persistent connection until a <a href="#header.connection" class="smpl">close</a> connection option is received in a request. |
| | 2181 | </p> |
| | 2182 | <p id="rfc.section.6.3.p.4">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option. |
| | 2183 | </p> |
| | 2184 | <p id="rfc.section.6.3.p.5">In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined |
| | 2185 | by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 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 |
| | 2186 | 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. |
| | 2187 | </p> |
| | 2188 | <p id="rfc.section.6.3.p.6">A proxy server <em class="bcp14">MUST NOT</em> maintain a persistent connection with an HTTP/1.0 client (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). |
| | 2189 | </p> |
| | 2190 | <p id="rfc.section.6.3.p.7">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. |
| | 2191 | </p> |
| | 2192 | <div id="persistent.retrying.requests"> |
| | 2193 | <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a href="#persistent.retrying.requests">Retrying Requests</a></h3> |
| | 2194 | <p id="rfc.section.6.3.1.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover |
| | 2195 | from asynchronous close events. |
| | 2196 | </p> |
| | 2197 | <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent |
| | 2198 | methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests. |
| | 2199 | </p> |
| | 2200 | <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are |
| | 2201 | actually idempotent, regardless of the method, or some means to detect that the original request was never applied. For example, |
| | 2202 | a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that |
| | 2203 | request automatically. Likewise, a user agent designed specifically to operate on a version control repository might be able |
| | 2204 | to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting |
| | 2205 | or fixing any changes that were partially applied, and then automatically retrying the requests that failed. |
| | 2206 | </p> |
| | 2207 | <p id="rfc.section.6.3.1.p.4">A client <em class="bcp14">SHOULD NOT</em> automatically retry a failed automatic retry. |
| | 2208 | </p> |
| | 2209 | </div> |
| | 2210 | <div id="pipelining"> |
| | 2211 | <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a href="#pipelining">Pipelining</a></h3> |
| | 2212 | <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received. |
| | 2213 | </p> |
| | 2214 | <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined |
| | 2215 | requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client <em class="bcp14">MUST NOT</em> pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused |
| | 2216 | an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset |
| | 2217 | problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section 6.6</a>). |
| | 2218 | </p> |
| | 2219 | <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless |
| | 2220 | the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence. |
| | 2221 | </p> |
| | 2222 | <p id="rfc.section.6.3.2.p.4">An intermediary that receives pipelined requests <em class="bcp14">MAY</em> pipeline those requests when forwarding them inbound, since it can rely on the outbound user agent(s) to determine what requests |
| | 2223 | can be safely pipelined. If the inbound connection fails before receiving a response, the pipelining intermediary <em class="bcp14">MAY</em> attempt to retry a sequence of requests that have yet to receive a response if the requests all have idempotent methods; otherwise, |
| | 2224 | the pipelining intermediary <em class="bcp14">SHOULD</em> forward any received responses and then close the corresponding outbound connection(s) so that the outbound user agent(s) |
| | 2225 | can recover accordingly. |
| | 2226 | </p> |
| | 2227 | </div> |
| | 2228 | </div> |
| | 2229 | <div id="persistent.concurrency"> |
| | 2230 | <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a href="#persistent.concurrency">Concurrency</a></h2> |
| | 2231 | <p id="rfc.section.6.4.p.1">A client <em class="bcp14">SHOULD</em> limit the number of simultaneous open connections that it maintains to a given server. |
| | 2232 | </p> |
| | 2233 | <p id="rfc.section.6.4.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many |
| | 2234 | applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages |
| | 2235 | clients to be conservative when opening multiple connections. |
| | 2236 | </p> |
| | 2237 | <p id="rfc.section.6.4.p.3">Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant |
| | 2238 | server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection |
| | 2239 | consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks. |
| | 2240 | </p> |
| | 2241 | <p id="rfc.section.6.4.p.4">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> |
| | 2242 | </div> |
| | 2243 | <div id="persistent.failures"> |
| | 2244 | <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a href="#persistent.failures">Failures and Time-outs</a></h2> |
| | 2245 | <p id="rfc.section.6.5.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers |
| | 2246 | might make this a higher value since it is likely that the client will be making more connections through the same server. |
| | 2247 | The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client |
| | 2248 | or the server. |
| | 2249 | </p> |
| | 2250 | <p id="rfc.section.6.5.p.2">A client or server that wishes to time-out <em class="bcp14">SHOULD</em> issue a graceful close on the connection. Implementations <em class="bcp14">SHOULD</em> constantly monitor open connections for a received closure signal and respond to it as appropriate, since prompt closure of |
| | 2251 | both sides of a connection enables allocated system resources to be reclaimed. |
| | 2252 | </p> |
| | 2253 | <p id="rfc.section.6.5.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 |
| | 2254 | that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed |
| | 2255 | while it was idle, but from the client's point of view, a request is in progress. |
| | 2256 | </p> |
| | 2257 | <p id="rfc.section.6.5.p.4">A server <em class="bcp14">SHOULD</em> sustain persistent connections, when possible, and allow the underlying transport's flow control mechanisms to resolve temporary |
| | 2258 | overloads, rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate |
| | 2259 | network congestion. |
| | 2260 | </p> |
| | 2261 | <p id="rfc.section.6.5.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error response while it is transmitting the request. If the client sees a response that |
| | 2262 | indicates the server does not wish to receive the message body and is closing the connection, the client <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close its side of the connection. |
| | 2263 | </p> |
| | 2264 | </div> |
| | 2265 | <div id="persistent.tear-down"> |
| | 2266 | <div id="rfc.iref.c.13"></div> |
| | 2267 | <div id="rfc.iref.c.14"></div> |
| | 2268 | <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a href="#persistent.tear-down">Tear-down</a></h2> |
| | 2269 | <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair. |
| | 2270 | </p> |
| | 2271 | <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. |
| | 2272 | </p> |
| | 2273 | <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> send a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. |
| | 2274 | </p> |
| | 2275 | <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. |
| | 2276 | </p> |
| | 2277 | <p id="rfc.section.6.6.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close; |
| | 2278 | if additional pipelined requests had been sent on the connection, the client <em class="bcp14">SHOULD NOT</em> assume that they will be processed by the server. |
| | 2279 | </p> |
| | 2280 | <p id="rfc.section.6.6.p.6">If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able |
| | 2281 | to read the last HTTP response. If the server receives additional data from the client on a fully-closed connection, such |
| | 2282 | as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a |
| | 2283 | reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they |
| | 2284 | can be read and interpreted by the client's HTTP parser. |
| | 2285 | </p> |
| | 2286 | <p id="rfc.section.6.6.p.7">To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by |
| | 2287 | closing only the write side of the read/write connection. The server then continues to read from the connection until it receives |
| | 2288 | a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's |
| | 2289 | acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection. |
| | 2290 | </p> |
| | 2291 | <p id="rfc.section.6.6.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p> |
| | 2292 | </div> |
| | 2293 | <div id="header.upgrade"> |
| | 2294 | <div id="rfc.iref.u.5"></div> |
| | 2295 | <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a href="#header.upgrade">Upgrade</a></h2> |
| | 2296 | <p id="rfc.section.6.7.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol |
| | 2297 | on the same connection. A client <em class="bcp14">MAY</em> send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols, |
| | 2298 | in order of descending preference, before sending the final response. A server <em class="bcp14">MAY</em> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. |
| | 2299 | </p> |
| | 2300 | <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.107"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> |
| 2340 | | <p id="rfc.section.8.1.p.3">Furthermore, the header field-name "Close" shall be registered as "reserved", since using that name as an HTTP header field |
| 2341 | | might conflict with the "close" connection option of the "<a href="#header.connection" class="smpl">Connection</a>" header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>). |
| 2342 | | </p> |
| 2343 | | <div id="rfc.table.u.1"> |
| 2344 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| 2345 | | <thead> |
| 2346 | | <tr> |
| 2347 | | <th>Header Field Name</th> |
| 2348 | | <th>Protocol</th> |
| 2349 | | <th>Status</th> |
| 2350 | | <th>Reference</th> |
| 2351 | | </tr> |
| 2352 | | </thead> |
| 2353 | | <tbody> |
| 2354 | | <tr> |
| 2355 | | <td class="left">Close</td> |
| 2356 | | <td class="left">http</td> |
| 2357 | | <td class="left">reserved</td> |
| 2358 | | <td class="left"><a href="#header.field.registration" title="Header Field Registration">Section 8.1</a> |
| 2359 | | </td> |
| 2360 | | </tr> |
| 2361 | | </tbody> |
| 2362 | | </table> |
| | 2391 | <div id="IANA.considerations"> |
| | 2392 | <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#IANA.considerations">IANA Considerations</a></h1> |
| | 2393 | <div id="header.field.registration"> |
| | 2394 | <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a href="#header.field.registration">Header Field Registration</a></h2> |
| | 2395 | <p id="rfc.section.8.1.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>. |
| | 2396 | </p> |
| | 2397 | <p id="rfc.section.8.1.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to |
| | 2398 | the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): |
| | 2399 | </p> |
| | 2400 | <div id="rfc.table.1"> |
| | 2401 | <div id="iana.header.registration.table"></div> |
| | 2402 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 2403 | <thead> |
| | 2404 | <tr> |
| | 2405 | <th>Header Field Name</th> |
| | 2406 | <th>Protocol</th> |
| | 2407 | <th>Status</th> |
| | 2408 | <th>Reference</th> |
| | 2409 | </tr> |
| | 2410 | </thead> |
| | 2411 | <tbody> |
| | 2412 | <tr> |
| | 2413 | <td class="left">Connection</td> |
| | 2414 | <td class="left">http</td> |
| | 2415 | <td class="left">standard</td> |
| | 2416 | <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a> |
| | 2417 | </td> |
| | 2418 | </tr> |
| | 2419 | <tr> |
| | 2420 | <td class="left">Content-Length</td> |
| | 2421 | <td class="left">http</td> |
| | 2422 | <td class="left">standard</td> |
| | 2423 | <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 3.3.2</a> |
| | 2424 | </td> |
| | 2425 | </tr> |
| | 2426 | <tr> |
| | 2427 | <td class="left">Host</td> |
| | 2428 | <td class="left">http</td> |
| | 2429 | <td class="left">standard</td> |
| | 2430 | <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 5.4</a> |
| | 2431 | </td> |
| | 2432 | </tr> |
| | 2433 | <tr> |
| | 2434 | <td class="left">TE</td> |
| | 2435 | <td class="left">http</td> |
| | 2436 | <td class="left">standard</td> |
| | 2437 | <td class="left"><a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a> |
| | 2438 | </td> |
| | 2439 | </tr> |
| | 2440 | <tr> |
| | 2441 | <td class="left">Trailer</td> |
| | 2442 | <td class="left">http</td> |
| | 2443 | <td class="left">standard</td> |
| | 2444 | <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 4.4</a> |
| | 2445 | </td> |
| | 2446 | </tr> |
| | 2447 | <tr> |
| | 2448 | <td class="left">Transfer-Encoding</td> |
| | 2449 | <td class="left">http</td> |
| | 2450 | <td class="left">standard</td> |
| | 2451 | <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 3.3.1</a> |
| | 2452 | </td> |
| | 2453 | </tr> |
| | 2454 | <tr> |
| | 2455 | <td class="left">Upgrade</td> |
| | 2456 | <td class="left">http</td> |
| | 2457 | <td class="left">standard</td> |
| | 2458 | <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.7</a> |
| | 2459 | </td> |
| | 2460 | </tr> |
| | 2461 | <tr> |
| | 2462 | <td class="left">Via</td> |
| | 2463 | <td class="left">http</td> |
| | 2464 | <td class="left">standard</td> |
| | 2465 | <td class="left"><a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 5.7.1</a> |
| | 2466 | </td> |
| | 2467 | </tr> |
| | 2468 | </tbody> |
| | 2469 | </table> |
| | 2470 | </div> |
| | 2471 | <p id="rfc.section.8.1.p.3">Furthermore, the header field-name "Close" shall be registered as "reserved", since using that name as an HTTP header field |
| | 2472 | might conflict with the "close" connection option of the "<a href="#header.connection" class="smpl">Connection</a>" header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>). |
| | 2473 | </p> |
| | 2474 | <div id="rfc.table.u.1"> |
| | 2475 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 2476 | <thead> |
| | 2477 | <tr> |
| | 2478 | <th>Header Field Name</th> |
| | 2479 | <th>Protocol</th> |
| | 2480 | <th>Status</th> |
| | 2481 | <th>Reference</th> |
| | 2482 | </tr> |
| | 2483 | </thead> |
| | 2484 | <tbody> |
| | 2485 | <tr> |
| | 2486 | <td class="left">Close</td> |
| | 2487 | <td class="left">http</td> |
| | 2488 | <td class="left">reserved</td> |
| | 2489 | <td class="left"><a href="#header.field.registration" title="Header Field Registration">Section 8.1</a> |
| | 2490 | </td> |
| | 2491 | </tr> |
| | 2492 | </tbody> |
| | 2493 | </table> |
| | 2494 | </div> |
| | 2495 | <p id="rfc.section.8.1.p.4">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> |
| | 2496 | </div> |
| | 2497 | <div id="uri.scheme.registration"> |
| | 2498 | <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a href="#uri.scheme.registration">URI Scheme Registration</a></h2> |
| | 2499 | <p id="rfc.section.8.2.p.1">IANA maintains the registry of URI Schemes <a href="#BCP115" id="rfc.xref.BCP115.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[BCP115]</cite></a> at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>>. |
| | 2500 | </p> |
| | 2501 | <p id="rfc.section.8.2.p.2">This document defines the following URI schemes, so their associated registry entries shall be updated according to the permanent |
| | 2502 | registrations below: |
| | 2503 | </p> |
| | 2504 | <div id="rfc.table.u.2"> |
| | 2505 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 2506 | <thead> |
| | 2507 | <tr> |
| | 2508 | <th>URI Scheme</th> |
| | 2509 | <th>Description</th> |
| | 2510 | <th>Reference</th> |
| | 2511 | </tr> |
| | 2512 | </thead> |
| | 2513 | <tbody> |
| | 2514 | <tr> |
| | 2515 | <td class="left">http</td> |
| | 2516 | <td class="left">Hypertext Transfer Protocol</td> |
| | 2517 | <td class="left"><a href="#http.uri" title="http URI scheme">Section 2.7.1</a></td> |
| | 2518 | </tr> |
| | 2519 | <tr> |
| | 2520 | <td class="left">https</td> |
| | 2521 | <td class="left">Hypertext Transfer Protocol Secure</td> |
| | 2522 | <td class="left"><a href="#https.uri" title="https URI scheme">Section 2.7.2</a></td> |
| | 2523 | </tr> |
| | 2524 | </tbody> |
| | 2525 | </table> |
| | 2526 | </div> |
| | 2527 | </div> |
| | 2528 | <div id="internet.media.type.http"> |
| | 2529 | <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a href="#internet.media.type.http">Internet Media Type Registration</a></h2> |
| | 2530 | <p id="rfc.section.8.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following |
| | 2531 | is to be registered with IANA (see <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>). |
| | 2532 | </p> |
| | 2533 | <div id="internet.media.type.message.http"> |
| | 2534 | <div id="rfc.iref.m.3"></div> |
| | 2535 | <div id="rfc.iref.m.4"></div> |
| | 2536 | <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a href="#internet.media.type.message.http">Internet Media Type message/http</a></h3> |
| | 2537 | <p id="rfc.section.8.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions |
| | 2538 | for all "message" types regarding line length and encodings. |
| | 2539 | </p> |
| | 2540 | <p id="rfc.section.8.3.1.p.2"></p> |
| | 2541 | <dl> |
| | 2542 | <dt>Type name:</dt> |
| | 2543 | <dd>message</dd> |
| | 2544 | <dt>Subtype name:</dt> |
| | 2545 | <dd>http</dd> |
| | 2546 | <dt>Required parameters:</dt> |
| | 2547 | <dd>none</dd> |
| | 2548 | <dt>Optional parameters:</dt> |
| | 2549 | <dd>version, msgtype |
| | 2550 | <dl> |
| | 2551 | <dt>version:</dt> |
| | 2552 | <dd>The HTTP-version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first |
| | 2553 | line of the body. |
| | 2554 | </dd> |
| | 2555 | <dt>msgtype:</dt> |
| | 2556 | <dd>The message type — "request" or "response". If not present, the type can be determined from the first line of the body.</dd> |
| | 2557 | </dl> |
| | 2558 | </dd> |
| | 2559 | <dt>Encoding considerations:</dt> |
| | 2560 | <dd>only "7bit", "8bit", or "binary" are permitted</dd> |
| | 2561 | <dt>Security considerations:</dt> |
| | 2562 | <dd>none</dd> |
| | 2563 | <dt>Interoperability considerations:</dt> |
| | 2564 | <dd>none</dd> |
| | 2565 | <dt>Published specification:</dt> |
| | 2566 | <dd>This specification (see <a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a>). |
| | 2567 | </dd> |
| | 2568 | <dt>Applications that use this media type:</dt> |
| | 2569 | <dt>Additional information:</dt> |
| | 2570 | <dd> |
| | 2571 | <dl> |
| | 2572 | <dt>Magic number(s):</dt> |
| | 2573 | <dd>none</dd> |
| | 2574 | <dt>File extension(s):</dt> |
| | 2575 | <dd>none</dd> |
| | 2576 | <dt>Macintosh file type code(s):</dt> |
| | 2577 | <dd>none</dd> |
| | 2578 | </dl> |
| | 2579 | </dd> |
| | 2580 | <dt>Person and email address to contact for further information:</dt> |
| | 2581 | <dd>See Authors Section.</dd> |
| | 2582 | <dt>Intended usage:</dt> |
| | 2583 | <dd>COMMON</dd> |
| | 2584 | <dt>Restrictions on usage:</dt> |
| | 2585 | <dd>none</dd> |
| | 2586 | <dt>Author:</dt> |
| | 2587 | <dd>See Authors Section.</dd> |
| | 2588 | <dt>Change controller:</dt> |
| | 2589 | <dd>IESG</dd> |
| | 2590 | </dl> |
| | 2591 | </div> |
| | 2592 | <div id="internet.media.type.application.http"> |
| | 2593 | <div id="rfc.iref.m.5"></div> |
| | 2594 | <div id="rfc.iref.a.5"></div> |
| | 2595 | <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a> <a href="#internet.media.type.application.http">Internet Media Type application/http</a></h3> |
| | 2596 | <p id="rfc.section.8.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p> |
| | 2597 | <p id="rfc.section.8.3.2.p.2"></p> |
| | 2598 | <dl> |
| | 2599 | <dt>Type name:</dt> |
| | 2600 | <dd>application</dd> |
| | 2601 | <dt>Subtype name:</dt> |
| | 2602 | <dd>http</dd> |
| | 2603 | <dt>Required parameters:</dt> |
| | 2604 | <dd>none</dd> |
| | 2605 | <dt>Optional parameters:</dt> |
| | 2606 | <dd>version, msgtype |
| | 2607 | <dl> |
| | 2608 | <dt>version:</dt> |
| | 2609 | <dd>The HTTP-version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first |
| | 2610 | line of the body. |
| | 2611 | </dd> |
| | 2612 | <dt>msgtype:</dt> |
| | 2613 | <dd>The message type — "request" or "response". If not present, the type can be determined from the first line of the body.</dd> |
| | 2614 | </dl> |
| | 2615 | </dd> |
| | 2616 | <dt>Encoding considerations:</dt> |
| | 2617 | <dd>HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when |
| | 2618 | transmitted via E-mail. |
| | 2619 | </dd> |
| | 2620 | <dt>Security considerations:</dt> |
| | 2621 | <dd>none</dd> |
| | 2622 | <dt>Interoperability considerations:</dt> |
| | 2623 | <dd>none</dd> |
| | 2624 | <dt>Published specification:</dt> |
| | 2625 | <dd>This specification (see <a href="#internet.media.type.application.http" title="Internet Media Type application/http">Section 8.3.2</a>). |
| | 2626 | </dd> |
| | 2627 | <dt>Applications that use this media type:</dt> |
| | 2628 | <dt>Additional information:</dt> |
| | 2629 | <dd> |
| | 2630 | <dl> |
| | 2631 | <dt>Magic number(s):</dt> |
| | 2632 | <dd>none</dd> |
| | 2633 | <dt>File extension(s):</dt> |
| | 2634 | <dd>none</dd> |
| | 2635 | <dt>Macintosh file type code(s):</dt> |
| | 2636 | <dd>none</dd> |
| | 2637 | </dl> |
| | 2638 | </dd> |
| | 2639 | <dt>Person and email address to contact for further information:</dt> |
| | 2640 | <dd>See Authors Section.</dd> |
| | 2641 | <dt>Intended usage:</dt> |
| | 2642 | <dd>COMMON</dd> |
| | 2643 | <dt>Restrictions on usage:</dt> |
| | 2644 | <dd>none</dd> |
| | 2645 | <dt>Author:</dt> |
| | 2646 | <dd>See Authors Section.</dd> |
| | 2647 | <dt>Change controller:</dt> |
| | 2648 | <dd>IESG</dd> |
| | 2649 | </dl> |
| | 2650 | </div> |
| | 2651 | </div> |
| | 2652 | <div id="transfer.coding.registry"> |
| | 2653 | <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a href="#transfer.coding.registry">Transfer Coding Registry</a></h2> |
| | 2654 | <p id="rfc.section.8.4.p.1">The HTTP Transfer Coding Registry defines the name space for transfer coding names. It is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. |
| | 2655 | </p> |
| | 2656 | <div id="transfer.coding.registry.procedure"> |
| | 2657 | <h3 id="rfc.section.8.4.1"><a href="#rfc.section.8.4.1">8.4.1</a> <a href="#transfer.coding.registry.procedure">Procedure</a></h3> |
| | 2658 | <p id="rfc.section.8.4.1.p.1">Registrations <em class="bcp14">MUST</em> include the following fields: |
| | 2659 | </p> |
| | 2660 | <ul> |
| | 2661 | <li>Name</li> |
| | 2662 | <li>Description</li> |
| | 2663 | <li>Pointer to specification text</li> |
| | 2664 | </ul> |
| | 2665 | <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. |
| | 2666 | </p> |
| | 2667 | <p id="rfc.section.8.4.1.p.3">Values to be added to this name space require IETF Review (see <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 specification. |
| | 2668 | </p> |
| | 2669 | <p id="rfc.section.8.4.1.p.4">Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.</p> |
| | 2670 | </div> |
| | 2671 | <div id="transfer.coding.registration"> |
| | 2672 | <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a> <a href="#transfer.coding.registration">Registration</a></h3> |
| | 2673 | <p id="rfc.section.8.4.2.p.1">The HTTP Transfer Coding Registry shall be updated with the registrations below:</p> |
| | 2674 | <div id="rfc.table.2"> |
| | 2675 | <div id="iana.transfer.coding.registration.table"></div> |
| | 2676 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 2677 | <thead> |
| | 2678 | <tr> |
| | 2679 | <th>Name</th> |
| | 2680 | <th>Description</th> |
| | 2681 | <th>Reference</th> |
| | 2682 | </tr> |
| | 2683 | </thead> |
| | 2684 | <tbody> |
| | 2685 | <tr> |
| | 2686 | <td class="left">chunked</td> |
| | 2687 | <td class="left">Transfer in a series of chunks</td> |
| | 2688 | <td class="left"><a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> |
| | 2689 | </td> |
| | 2690 | </tr> |
| | 2691 | <tr> |
| | 2692 | <td class="left">compress</td> |
| | 2693 | <td class="left">UNIX "compress" data format <a href="#Welch" id="rfc.xref.Welch.2"><cite title="A Technique for High Performance Data Compression">[Welch]</cite></a></td> |
| | 2694 | <td class="left"><a href="#compress.coding" title="Compress Coding">Section 4.2.1</a> |
| | 2695 | </td> |
| | 2696 | </tr> |
| | 2697 | <tr> |
| | 2698 | <td class="left">deflate</td> |
| | 2699 | <td class="left">"deflate" compressed data (<a href="#RFC1951" id="rfc.xref.RFC1951.2"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.2"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) |
| | 2700 | </td> |
| | 2701 | <td class="left"><a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a> |
| | 2702 | </td> |
| | 2703 | </tr> |
| | 2704 | <tr> |
| | 2705 | <td class="left">gzip</td> |
| | 2706 | <td class="left">GZIP file format <a href="#RFC1952" id="rfc.xref.RFC1952.2"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> |
| | 2707 | <td class="left"><a href="#gzip.coding" title="Gzip Coding">Section 4.2.3</a> |
| | 2708 | </td> |
| | 2709 | </tr> |
| | 2710 | <tr> |
| | 2711 | <td class="left">x-compress</td> |
| | 2712 | <td class="left">Deprecated (alias for compress)</td> |
| | 2713 | <td class="left"><a href="#compress.coding" title="Compress Coding">Section 4.2.1</a> |
| | 2714 | </td> |
| | 2715 | </tr> |
| | 2716 | <tr> |
| | 2717 | <td class="left">x-gzip</td> |
| | 2718 | <td class="left">Deprecated (alias for gzip)</td> |
| | 2719 | <td class="left"><a href="#gzip.coding" title="Gzip Coding">Section 4.2.3</a> |
| | 2720 | </td> |
| | 2721 | </tr> |
| | 2722 | </tbody> |
| | 2723 | </table> |
| | 2724 | </div> |
| | 2725 | </div> |
| | 2726 | </div> |
| | 2727 | <div id="upgrade.token.registry"> |
| | 2728 | <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a href="#upgrade.token.registry">Upgrade Token Registry</a></h2> |
| | 2729 | <p id="rfc.section.8.5.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the <a href="#header.upgrade" class="smpl">Upgrade</a> header field. The registry is maintained at <<a href="http://www.iana.org/assignments/http-upgrade-tokens">http://www.iana.org/assignments/http-upgrade-tokens</a>>. |
| | 2730 | </p> |
| | 2731 | <div id="upgrade.token.registry.procedure"> |
| | 2732 | <h3 id="rfc.section.8.5.1"><a href="#rfc.section.8.5.1">8.5.1</a> <a href="#upgrade.token.registry.procedure">Procedure</a></h3> |
| | 2733 | <p id="rfc.section.8.5.1.p.1">Each registered protocol name is associated with contact information and an optional set of specifications that details how |
| | 2734 | the connection will be processed after it has been upgraded. |
| | 2735 | </p> |
| | 2736 | <p id="rfc.section.8.5.1.p.2">Registrations happen on a "First Come First Served" basis (see <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>) and are subject to the following rules: |
| | 2737 | </p> |
| | 2738 | <ol> |
| | 2739 | <li>A protocol-name token, once registered, stays registered forever.</li> |
| | 2740 | <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration. |
| | 2741 | </li> |
| | 2742 | <li>The registration <em class="bcp14">MUST</em> name a point of contact. |
| | 2743 | </li> |
| | 2744 | <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available. |
| | 2745 | </li> |
| | 2746 | <li>The registration <em class="bcp14">SHOULD</em> name a set of expected "protocol-version" tokens associated with that token at the time of registration. |
| | 2747 | </li> |
| | 2748 | <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. |
| | 2749 | </li> |
| | 2750 | <li>The IESG <em class="bcp14">MAY</em> reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot |
| | 2751 | be contacted. |
| | 2752 | </li> |
| | 2753 | </ol> |
| | 2754 | <p id="rfc.section.8.5.1.p.3">This registration procedure for HTTP Upgrade Tokens replaces that previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. |
| | 2755 | </p> |
| | 2756 | </div> |
| | 2757 | <div id="upgrade.token.registration"> |
| | 2758 | <h3 id="rfc.section.8.5.2"><a href="#rfc.section.8.5.2">8.5.2</a> <a href="#upgrade.token.registration">Upgrade Token Registration</a></h3> |
| | 2759 | <p id="rfc.section.8.5.2.p.1">The HTTP Upgrade Token Registry shall be updated with the registration below:</p> |
| | 2760 | <div id="rfc.table.u.3"> |
| | 2761 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 2762 | <thead> |
| | 2763 | <tr> |
| | 2764 | <th>Value</th> |
| | 2765 | <th>Description</th> |
| | 2766 | <th>Expected Version Tokens</th> |
| | 2767 | <th>Reference</th> |
| | 2768 | </tr> |
| | 2769 | </thead> |
| | 2770 | <tbody> |
| | 2771 | <tr> |
| | 2772 | <td class="left">HTTP</td> |
| | 2773 | <td class="left">Hypertext Transfer Protocol</td> |
| | 2774 | <td class="left">any DIGIT.DIGIT (e.g, "2.0")</td> |
| | 2775 | <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2.6</a></td> |
| | 2776 | </tr> |
| | 2777 | </tbody> |
| | 2778 | </table> |
| | 2779 | </div> |
| | 2780 | <p id="rfc.section.8.5.2.p.2">The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> |
| | 2781 | </div> |
| | 2782 | </div> |
| 2364 | | <p id="rfc.section.8.1.p.4">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> |
| 2365 | | <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> |
| 2366 | | <p id="rfc.section.8.2.p.1">IANA maintains the registry of URI Schemes <a href="#BCP115" id="rfc.xref.BCP115.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[BCP115]</cite></a> at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>>. |
| 2367 | | </p> |
| 2368 | | <p id="rfc.section.8.2.p.2">This document defines the following URI schemes, so their associated registry entries shall be updated according to the permanent |
| 2369 | | registrations below: |
| 2370 | | </p> |
| 2371 | | <div id="rfc.table.u.2"> |
| 2372 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| 2373 | | <thead> |
| 2374 | | <tr> |
| 2375 | | <th>URI Scheme</th> |
| 2376 | | <th>Description</th> |
| 2377 | | <th>Reference</th> |
| 2378 | | </tr> |
| 2379 | | </thead> |
| 2380 | | <tbody> |
| 2381 | | <tr> |
| 2382 | | <td class="left">http</td> |
| 2383 | | <td class="left">Hypertext Transfer Protocol</td> |
| 2384 | | <td class="left"><a href="#http.uri" title="http URI scheme">Section 2.7.1</a></td> |
| 2385 | | </tr> |
| 2386 | | <tr> |
| 2387 | | <td class="left">https</td> |
| 2388 | | <td class="left">Hypertext Transfer Protocol Secure</td> |
| 2389 | | <td class="left"><a href="#https.uri" title="https URI scheme">Section 2.7.2</a></td> |
| 2390 | | </tr> |
| 2391 | | </tbody> |
| 2392 | | </table> |
| | 2784 | <div id="security.considerations"> |
| | 2785 | <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#security.considerations">Security Considerations</a></h1> |
| | 2786 | <p id="rfc.section.9.p.1">This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP/1.1 |
| | 2787 | message syntax, parsing, and routing. |
| | 2788 | </p> |
| | 2789 | <div id="dns.related.attacks"> |
| | 2790 | <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a href="#dns.related.attacks">DNS-related Attacks</a></h2> |
| | 2791 | <p id="rfc.section.9.1.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the |
| | 2792 | deliberate misassociation of IP addresses and DNS names not protected by DNSSEC. Clients need to be cautious in assuming the |
| | 2793 | validity of an IP number/DNS name association unless the response is protected by DNSSEC (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>). |
| | 2794 | </p> |
| | 2795 | </div> |
| | 2796 | <div id="attack.intermediaries"> |
| | 2797 | <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a href="#attack.intermediaries">Intermediaries and Caching</a></h2> |
| | 2798 | <p id="rfc.section.9.2.p.1">By their very nature, HTTP intermediaries are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. |
| | 2799 | Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries |
| | 2800 | have access to security-related information, personal information about individual users and organizations, and proprietary |
| | 2801 | information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured |
| | 2802 | without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks. |
| | 2803 | </p> |
| | 2804 | <p id="rfc.section.9.2.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks.</p> |
| | 2805 | <p id="rfc.section.9.2.p.3">Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration |
| | 2806 | options they provide to operators (especially the default configuration). |
| | 2807 | </p> |
| | 2808 | <p id="rfc.section.9.2.p.4">Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve |
| | 2809 | this problem. |
| | 2810 | </p> |
| | 2811 | </div> |
| | 2812 | <div id="attack.protocol.element.size.overflows"> |
| | 2813 | <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a href="#attack.protocol.element.size.overflows">Buffer Overflows</a></h2> |
| | 2814 | <p id="rfc.section.9.3.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform |
| | 2815 | a Denial of Service against implementations that accept fields with unlimited lengths. |
| | 2816 | </p> |
| | 2817 | <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section 3.1.1</a>) and header fields (<a href="#header.fields" title="Header Fields">Section 3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected |
| | 2818 | that most implementations will choose substantially higher limits. |
| | 2819 | </p> |
| | 2820 | <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>. |
| | 2821 | </p> |
| | 2822 | <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods, |
| | 2823 | response status phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability. |
| | 2824 | </p> |
| | 2825 | </div> |
| | 2826 | <div id="message.integrity"> |
| | 2827 | <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a href="#message.integrity">Message Integrity</a></h2> |
| | 2828 | <p id="rfc.section.9.4.p.1">HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of |
| | 2829 | underlying transport protocols and the use of length or chunk-delimited framing to detect completeness. Additional integrity |
| | 2830 | mechanisms, such as hash functions or digital signatures applied to the content, can be selectively added to messages via |
| | 2831 | extensible metadata header fields. Historically, the lack of a single integrity mechanism has been justified by the informal |
| | 2832 | nature of most HTTP communication. However, the prevalence of HTTP as an information access mechanism has resulted in its |
| | 2833 | increasing use within environments where verification of message integrity is crucial. |
| | 2834 | </p> |
| | 2835 | <p id="rfc.section.9.4.p.2">User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such |
| | 2836 | that those means can be enabled within environments for which integrity is necessary. For example, a browser being used to |
| | 2837 | view medical history or drug interaction information needs to indicate to the user when such information is detected by the |
| | 2838 | protocol to be incomplete, expired, or corrupted during transfer. Such mechanisms might be selectively enabled via user agent |
| | 2839 | extensions or the presence of message integrity metadata in a response. At a minimum, user agents ought to provide some indication |
| | 2840 | that allows a user to distinguish between a complete and incomplete response message (<a href="#incomplete.messages" title="Handling Incomplete Messages">Section 3.4</a>) when such verification is desired. |
| | 2841 | </p> |
| | 2842 | </div> |
| | 2843 | <div id="abuse.of.server.log.information"> |
| | 2844 | <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a href="#abuse.of.server.log.information">Server Log Information</a></h2> |
| | 2845 | <p id="rfc.section.9.5.p.1">A server is in the position to save personal data about a user's requests over time, which might identify their reading patterns |
| | 2846 | or subjects of interest. In particular, log information gathered at an intermediary often contains a history of user agent |
| | 2847 | interaction, across a multitude of sites, that can be traced to individual users. |
| | 2848 | </p> |
| | 2849 | <p id="rfc.section.9.5.p.2">HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information |
| | 2850 | needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within |
| | 2851 | individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation |
| | 2852 | with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if |
| | 2853 | the key is pseudonymous. |
| | 2854 | </p> |
| | 2855 |
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)