![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1575
- Timestamp:
- 10/03/12 10:57:18 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p1-messaging.html (modified) (37 diffs)
-
p1-messaging.xml (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1574 r1575 460 460 } 461 461 @bottom-center { 462 content: "Expires September 1 0, 2012";462 content: "Expires September 11, 2012"; 463 463 } 464 464 @bottom-right { … … 510 510 <meta name="dct.creator" content="Reschke, J. F."> 511 511 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 512 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 09">512 <meta name="dct.issued" scheme="ISO8601" content="2012-03-10"> 513 513 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 542 542 </tr> 543 543 <tr> 544 <td class="left">Expires: September 1 0, 2012</td>544 <td class="left">Expires: September 11, 2012</td> 545 545 <td class="right">HP</td> 546 546 </tr> … … 595 595 <tr> 596 596 <td class="left"></td> 597 <td class="right">March 9, 2012</td>597 <td class="right">March 10, 2012</td> 598 598 </tr> 599 599 </tbody> … … 628 628 in progress”. 629 629 </p> 630 <p>This Internet-Draft will expire on September 1 0, 2012.</p>630 <p>This Internet-Draft will expire on September 11, 2012.</p> 631 631 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 632 632 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 670 670 <li>3.1.1 <a href="#request.line">Request Line</a><ul> 671 671 <li>3.1.1.1 <a href="#method">Method</a></li> 672 <li>3.1.1.2 <a href="#request-target"> request-target</a></li>672 <li>3.1.1.2 <a href="#request-target">Request Target</a></li> 673 673 </ul> 674 674 </li> … … 715 715 </li> 716 716 <li>5. <a href="#message.routing">Message Routing</a><ul> 717 <li>5.1 <a href="#request-target-types">Types of Request Target</a></li> 718 <li>5.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 719 <li>5.3 <a href="#effective.request.uri">Effective Request URI</a></li> 720 <li>5.4 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 717 <li>5.1 <a href="#target-resource">Identifying a Target Resource</a></li> 718 <li>5.2 <a href="#connecting.inbound">Connecting Inbound</a></li> 719 <li>5.3 <a href="#request-target-types">Types of Request Target</a></li> 720 <li>5.4 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 721 <li>5.5 <a href="#effective.request.uri">Effective Request URI</a></li> 722 <li>5.6 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 721 723 </ul> 722 724 </li> … … 1250 1252 </pre><p id="rfc.section.3.1.1.1.p.3">The methods defined by this specification can be found in <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1251 1253 </p> 1252 <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a id="request-target" href="#request-target"> request-target</a></h4>1254 <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a id="request-target" href="#request-target">Request Target</a></h4> 1253 1255 <p id="rfc.section.3.1.1.2.p.1">The request-target identifies the target resource upon which to apply the request. The four options for request-target are 1254 described in <a href="#request-target-types" title="Types of Request Target">Section 5. 1</a>.1256 described in <a href="#request-target-types" title="Types of Request Target">Section 5.3</a>. 1255 1257 </p> 1256 1258 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#request-target" class="smpl">request-target</a> = "*" … … 1842 1844 </ul> 1843 1845 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> 1844 <p id="rfc.section.5.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target 1845 resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target. 1846 </p> 1847 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2> 1848 <p id="rfc.section.5.1.p.1">The proper format choice of the four options available to request-target depends on the method being requested and if the 1849 request is being made to a proxy. 1846 <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, 1847 and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain 1848 back to the client. 1849 </p> 1850 <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> 1851 <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, 1852 communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification 1853 mechanism and configuration techniques as general-purpose Web browsers. 1854 </p> 1855 <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 1856 are defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the target resource, which a user agent would resolve to its absolute form in order 1857 to obtain the target URI. The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers 1858 are for client-side processing only. 1859 </p> 1860 <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p> 1861 <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> 1862 <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 1863 semantics and, if so, where that request is to be directed. 1864 </p> 1865 <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), then the request is usually directed to the cache first. 1866 </p> 1867 <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 1868 is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, 1869 selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy 1870 is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. 1871 </p> 1872 <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 1873 connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and 1874 defined by its associated specification, similar to how this specification defines origin server access for resolution of 1875 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. 1876 </p> 1877 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2> 1878 <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 (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>), depending on both the method being requested and whether the request is to a proxy. 1850 1879 </p> 1851 1880 <div id="origin-form"> 1852 <p id="rfc.section.5. 1.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a1881 <p id="rfc.section.5.3.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a 1853 1882 resource identified by an "http" (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) URI. In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target and the authority component (excluding any userinfo) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource identified 1854 1883 as … … 1856 1885 </div> 1857 1886 <div id="rfc.figure.u.46"></div><pre>http://www.example.org/where?q=now 1858 </pre><p id="rfc.section.5. 1.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the1887 </pre><p id="rfc.section.5.3.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the 1859 1888 lines: 1860 1889 </p> 1861 1890 <div id="rfc.figure.u.47"></div><pre class="text2">GET /where?q=now HTTP/1.1 1862 1891 Host: www.example.org 1863 </pre><p id="rfc.section.5. 1.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.1892 </pre><p id="rfc.section.5.3.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path. 1864 1893 If the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target. 1865 1894 </p> 1866 <p id="rfc.section.5. 1.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.1895 <p id="rfc.section.5.3.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1867 1896 </p> 1868 1897 <div id="absolute-URI-form"> 1869 <p id="rfc.section.5. 1.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid1898 <p id="rfc.section.5.3.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid 1870 1899 cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request 1871 1900 loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses. … … 1874 1903 </div> 1875 1904 <div id="rfc.figure.u.48"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1876 </pre><p id="rfc.section.5. 1.p.10">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.1877 </p> 1878 <p id="rfc.section.5. 1.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.1905 </pre><p id="rfc.section.5.3.p.10">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1906 </p> 1907 <p id="rfc.section.5.3.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1879 1908 </p> 1880 1909 <div id="authority-form"> 1881 <p id="rfc.section.5. 1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,1910 <p id="rfc.section.5.3.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example, 1882 1911 </p> 1883 1912 </div> 1884 1913 <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1885 1914 </pre><div id="asterix-form"> 1886 <p id="rfc.section.5. 1.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening1915 <p id="rfc.section.5.3.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening 1887 1916 process) rather than to a specific named resource at that server. For example, 1888 1917 </p> 1889 1918 </div> 1890 1919 <div id="rfc.figure.u.50"></div><pre class="text2">OPTIONS * HTTP/1.1 1891 </pre><p id="rfc.section.5. 1.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and1920 </pre><p id="rfc.section.5.3.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and 1892 1921 no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server. 1893 1922 </p> … … 1898 1927 Host: www.example.org:8001 1899 1928 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> 1900 <p id="rfc.section.5. 1.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,1929 <p id="rfc.section.5.3.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1901 1930 except as noted above to replace a null path-absolute with "/" or "*". 1902 1931 </p> 1903 <h2 id="rfc.section.5. 2"><a href="#rfc.section.5.2">5.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>1904 <p id="rfc.section.5. 2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header1932 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> 1933 <p id="rfc.section.5.4.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header 1905 1934 field. 1906 1935 </p> 1907 <p id="rfc.section.5. 2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix A.1.1</a> for other requirements on Host support in HTTP/1.1.)1908 </p> 1909 <p id="rfc.section.5. 2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or1936 <p id="rfc.section.5.4.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix A.1.1</a> for other requirements on Host support in HTTP/1.1.) 1937 </p> 1938 <p id="rfc.section.5.4.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or 1910 1939 vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request: 1911 1940 </p> … … 1919 1948 </li> 1920 1949 </ol> 1921 <p id="rfc.section.5. 2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine1950 <p id="rfc.section.5.4.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine 1922 1951 what exact resource is being requested. 1923 1952 </p> 1924 1953 <div id="rfc.iref.e.1"></div> 1925 1954 <div id="rfc.iref.t.7"></div> 1926 <h2 id="rfc.section.5. 3"><a href="#rfc.section.5.3">5.3</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2>1927 <p id="rfc.section.5. 3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection1955 <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> 1956 <p id="rfc.section.5.5.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection 1928 1957 context. The result of this process is called the "effective request URI". The "target resource" is the resource identified 1929 1958 by the effective request URI. 1930 1959 </p> 1931 <p id="rfc.section.5. 3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p>1932 <p id="rfc.section.5. 3.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective1960 <p id="rfc.section.5.5.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p> 1961 <p id="rfc.section.5.5.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective 1933 1962 request URI is constructed by concatenating 1934 1963 </p> 1935 <p id="rfc.section.5. 3.p.4"> </p>1964 <p id="rfc.section.5.5.p.4"> </p> 1936 1965 <ul> 1937 1966 <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured … … 1943 1972 <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li> 1944 1973 </ul> 1945 <p id="rfc.section.5. 3.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective1974 <p id="rfc.section.5.5.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective 1946 1975 request URI is undefined. 1947 1976 </p> 1948 <p id="rfc.section.5. 3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>1977 <p id="rfc.section.5.5.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 1949 1978 <div id="rfc.figure.u.53"></div> 1950 1979 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 … … 1959 1988 thus "https://www.example.org". 1960 1989 </p> 1961 <p id="rfc.section.5. 3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".1962 </p> 1963 <h2 id="rfc.section.5. 4"><a href="#rfc.section.5.4">5.4</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>1964 <p id="rfc.section.5. 4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response1990 <p id="rfc.section.5.5.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 1991 </p> 1992 <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> 1993 <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 1965 1994 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1966 1995 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 1967 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.1968 </p> 1969 <p id="rfc.section.5. 4.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.1996 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request. 1997 </p> 1998 <p id="rfc.section.5.6.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response. 1970 1999 </p> 1971 2000 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connections" href="#connections">Connections</a></h1> … … 2023 2052 <p id="rfc.section.6.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2024 2053 </p> 2025 <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2054 <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2026 2055 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2027 2056 </p> … … 2086 2115 <li>Content-Type</li> 2087 2116 </ul> 2088 <p id="rfc.section.6.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6. 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).2117 <p id="rfc.section.6.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 2089 2118 </p> 2090 2119 <div class="note" id="rfc.section.6.1.3.2.p.7"> … … 2122 2151 <h3 id="rfc.section.6.1.5"><a href="#rfc.section.6.1.5">6.1.5</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2123 2152 <p id="rfc.section.6.1.5.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2124 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding2153 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2125 2154 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2126 2155 </p> … … 2135 2164 </p> 2136 2165 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2137 <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2166 <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2138 2167 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2139 2168 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2142 2171 <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 2143 2172 <ul> 2144 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2145 </li> 2146 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.2173 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 2174 </li> 2175 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 2147 2176 </li> 2148 2177 </ul> … … 2188 2217 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2189 2218 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2190 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2219 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2191 2220 </li> 2192 2221 </ul> … … 2277 2306 </p> 2278 2307 <p id="rfc.section.8.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 2279 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6. 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).2308 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 2280 2309 </p> 2281 2310 <p id="rfc.section.8.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header … … 2328 2357 message that contains more than one Host header field or a Host header field with an invalid field-value. 2329 2358 </p> 2330 <p id="rfc.section.8.2.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5. 2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.2359 <p id="rfc.section.8.2.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.4</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host. 2331 2360 </p> 2332 2361 <div id="rfc.iref.u.5"></div> … … 2358 2387 </p> 2359 2388 <p id="rfc.section.8.3.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2360 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2389 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2361 2390 </p> 2362 2391 <p id="rfc.section.8.3.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched … … 2775 2804 a Denial of Service against implementations that accept fields with unlimited lengths. 2776 2805 </p> 2777 <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title=" request-target">Section 3.1.1.2</a>) and blocks of 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 expected2806 <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>) and blocks of 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 2778 2807 that most implementations will choose substantially higher limits. 2779 2808 </p> 2780 <p id="rfc.section.10.6.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 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.1 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2809 <p id="rfc.section.10.6.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 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2781 2810 </p> 2782 2811 <p id="rfc.section.10.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. … … 3046 3075 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3047 3076 <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3> 3048 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section 8.2</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title=" request-target">Section 3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.3077 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section 8.2</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>) are among the most important changes defined by HTTP/1.1. 3049 3078 </p> 3050 3079 <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism … … 3078 3107 </p> 3079 3108 <p id="rfc.section.A.2.p.2">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk 3080 form is allowed for the OPTIONS request method only. (<a href="#request-target" title=" request-target">Section 3.1.1.2</a>)3109 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>) 3081 3110 </p> 3082 3111 <p id="rfc.section.A.2.p.3">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) … … 3638 3667 <ul class="ind"> 3639 3668 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3640 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.2">5. 1</a></li>3669 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.2">5.3</a></li> 3641 3670 <li>accelerator <a href="#rfc.iref.a.1"><b>2.3</b></a></li> 3642 3671 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>9.3.2</b></a></li> 3643 <li>asterisk form (of request-target) <a href="#rfc.iref.a.4">5. 1</a></li>3644 <li>authority form (of request-target) <a href="#rfc.iref.a.3">5. 1</a></li>3672 <li>asterisk form (of request-target) <a href="#rfc.iref.a.4">5.3</a></li> 3673 <li>authority form (of request-target) <a href="#rfc.iref.a.3">5.3</a></li> 3645 3674 </ul> 3646 3675 </li> … … 3675 3704 </li> 3676 3705 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3677 <li>effective request URI <a href="#rfc.iref.e.1"><b>5. 3</b></a></li>3706 <li>effective request URI <a href="#rfc.iref.e.1"><b>5.5</b></a></li> 3678 3707 </ul> 3679 3708 </li> … … 3780 3809 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.h.10"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.3</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3781 3810 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3782 <li>Host <a href="#rfc.xref.header.host.1">5. 3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.12"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>3811 <li>Host <a href="#rfc.xref.header.host.1">5.5</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.12"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3783 3812 <li>TE <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.h.8"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3784 3813 <li>Trailer <a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> … … 3790 3819 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3791 3820 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3792 <li>Host header field <a href="#rfc.xref.header.host.1">5. 3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.11"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>3821 <li>Host header field <a href="#rfc.xref.header.host.1">5.5</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.11"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3793 3822 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3794 3823 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3823 3852 </li> 3824 3853 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3825 <li>origin form (of request-target) <a href="#rfc.iref.o.3">5. 1</a></li>3854 <li>origin form (of request-target) <a href="#rfc.iref.o.3">5.3</a></li> 3826 3855 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3827 3856 <li>outbound <a href="#rfc.iref.o.2"><b>2.3</b></a></li> … … 3830 3859 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3831 3860 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3832 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5. 4</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.3</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>3861 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.6</a>, <a href="#rfc.xref.Part2.11">6.1.2.2</a>, <a href="#rfc.xref.Part2.12">6.1.5</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a>, <a href="#rfc.xref.Part2.17">8.3</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3833 3862 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li> 3834 3863 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3835 3864 <li><em>Section 4</em> <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li> 3836 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.1 0">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a></li>3837 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2. 8">5.1</a></li>3838 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2. 9">5.4</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>3839 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.1 2">6.2.3</a></li>3865 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.11">6.1.2.2</a>, <a href="#rfc.xref.Part2.12">6.1.5</a></li> 3866 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.9">5.3</a></li> 3867 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.10">5.6</a>, <a href="#rfc.xref.Part2.16">6.2.3</a></li> 3868 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.13">6.2.3</a></li> 3840 3869 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> 3841 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.1 6">8.3</a></li>3842 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.1 8">10.6</a></li>3843 <li><em>Section 7.4.12</em> <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.1 7">10.6</a></li>3870 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.17">8.3</a></li> 3871 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.19">10.6</a></li> 3872 <li><em>Section 7.4.12</em> <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.18">10.6</a></li> 3844 3873 <li><em>Section 10.2</em> <a href="#rfc.xref.Part2.6">3.2</a></li> 3845 <li><em>Section 10.3</em> <a href="#rfc.xref.Part2.1 3">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li>3874 <li><em>Section 10.3</em> <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li> 3846 3875 </ul> 3847 3876 </li> … … 3852 3881 </ul> 3853 3882 </li> 3854 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5"> 6.1.3.2</a>, <a href="#rfc.xref.Part6.6">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>3883 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">6.1.3.2</a>, <a href="#rfc.xref.Part6.7">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul> 3855 3884 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2.4</a></li> 3856 3885 <li><em>Section 2.1</em> <a href="#rfc.xref.Part6.4">3.4</a></li> 3857 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6. 6">8.1</a></li>3858 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6. 5">6.1.3.2</a></li>3886 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.7">8.1</a></li> 3887 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.6">6.1.3.2</a></li> 3859 3888 </ul> 3860 3889 </li> … … 3896 3925 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li> 3897 3926 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li> 3898 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">5. 1</a>, <a href="#rfc.xref.RFC3986.20">5.3</a>, <a href="#RFC3986"><b>12.1</b></a><ul>3899 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">5. 1</a></li>3927 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">5.3</a>, <a href="#rfc.xref.RFC3986.20">5.5</a>, <a href="#RFC3986"><b>12.1</b></a><ul> 3928 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">5.3</a></li> 3900 3929 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.7</a></li> 3901 3930 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2.7.1</a></li> … … 3907 3936 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3908 3937 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</a></li> 3909 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5. 3</a></li>3938 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.5</a></li> 3910 3939 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2.7.3</a></li> 3911 3940 </ul> … … 3938 3967 </li> 3939 3968 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3940 <li>target resource <a href="#rfc.iref.t.7"><b>5. 3</b></a></li>3969 <li>target resource <a href="#rfc.iref.t.7"><b>5.5</b></a></li> 3941 3970 <li>TE header field <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.t.5"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3942 3971 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1574 r1575 1136 1136 </section> 1137 1137 1138 <section title=" request-target" anchor="request-target">1138 <section title="Request Target" anchor="request-target"> 1139 1139 <x:anchor-alias value="request-target"/> 1140 1140 <t> … … 2295 2295 <section title="Message Routing" anchor="message.routing"> 2296 2296 <t> 2297 In most cases, the user agent is provided a URI reference 2298 from which it determines an absolute URI for identifying the target 2299 resource. When a request to the resource is initiated, all or part 2300 of that URI is used to construct the HTTP request-target. 2301 </t> 2297 HTTP request message routing is determined by each client based on the 2298 target resource, the client's proxy configuration, and 2299 establishment or reuse of an inbound connection. The corresponding 2300 response routing follows the same connection chain back to the client. 2301 </t> 2302 2303 <section title="Identifying a Target Resource" anchor="target-resource"> 2304 <t> 2305 HTTP is used in a wide variety of applications, ranging from 2306 general-purpose computers to home appliances. In some cases, 2307 communication options are hard-coded in a client's configuration. 2308 However, most HTTP clients rely on the same resource identification 2309 mechanism and configuration techniques as general-purpose Web browsers. 2310 </t> 2311 <t> 2312 HTTP communication is initiated by a user agent for some purpose. 2313 The purpose is a combination of request semantics, which are defined in 2314 <xref target="Part2"/>, and a target resource upon which to apply those 2315 semantics. A URI reference (<xref target="uri"/>) is typically used as 2316 an identifier for the target resource, which a user agent would resolve to 2317 its absolute form in order to obtain the target URI. The target URI 2318 excludes the reference's fragment identifier component, if any, 2319 since fragment identifiers are for client-side processing only. 2320 </t> 2321 <t> 2322 HTTP intermediaries obtain the request semantics and target URI 2323 from the request-line of an incoming request message. 2324 </t> 2325 </section> 2326 2327 <section title="Connecting Inbound" anchor="connecting.inbound"> 2328 <t> 2329 Once the target URI is determined, a client needs to decide whether 2330 a network request is necessary to accomplish the desired semantics and, 2331 if so, where that request is to be directed. 2332 </t> 2333 <t> 2334 If the client has a response cache and the request semantics can be 2335 satisfied by a cache (<xref target="Part6"/>), then the request is 2336 usually directed to the cache first. 2337 </t> 2338 <t> 2339 If the request is not satisfied by a cache, then a typical client will 2340 check its configuration to determine whether a proxy is to be used to 2341 satisfy the request. Proxy configuration is implementation-dependent, 2342 but is often based on URI prefix matching, selective authority matching, 2343 or both, and the proxy itself is usually identified by an "http" or 2344 "https" URI. If a proxy is applicable, the client connects inbound by 2345 establishing (or reusing) a connection to that proxy. 2346 </t> 2347 <t> 2348 If no proxy is applicable, a typical client will invoke a handler routine, 2349 usually specific to the target URI's scheme, to connect directly 2350 to an authority for the target resource. How that is accomplished is 2351 dependent on the target URI scheme and defined by its associated 2352 specification, similar to how this specification defines origin server 2353 access for resolution of the "http" (<xref target="http.uri"/>) and 2354 "https" (<xref target="https.uri"/>) schemes. 2355 </t> 2356 </section> 2302 2357 2303 2358 <section title="Types of Request Target" anchor="request-target-types"> 2304 2359 <t> 2305 The proper format choice of the four options available to request-target 2306 depends on the method being requested and if the request is being made to 2307 a proxy. 2360 Once an inbound connection is obtained, the client sends an HTTP request 2361 message (<xref target="http.message"/>) with a request-target derived from 2362 the target URI. There are four distinct formats for the request-target 2363 (<xref target="request-target"/>), depending on both the method being 2364 requested and whether the request is to a proxy. 2308 2365 </t> 2309 2366 <t anchor="origin-form"><iref item="origin form (of request-target)"/>
Note: See TracChangeset
for help on using the changeset viewer.
