Changeset 1576
- Timestamp:
- Mar 10, 2012, 3:07:51 AM (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1575 r1576 718 718 <li>5.2 <a href="#connecting.inbound">Connecting Inbound</a></li> 719 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> 720 <li>5.4 <a href="#header.host">Host</a></li> 721 <li>5.5 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 722 <li>5.6 <a href="#effective.request.uri">Effective Request URI</a></li> 723 <li>5.7 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 723 724 </ul> 724 725 </li> … … 759 760 <li>8. <a href="#header.field.definitions">Header Field Definitions</a><ul> 760 761 <li>8.1 <a href="#header.connection">Connection</a></li> 761 <li>8.2 <a href="#header.host">Host</a></li> 762 <li>8.3 <a href="#header.upgrade">Upgrade</a><ul> 763 <li>8.3.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 762 <li>8.2 <a href="#header.upgrade">Upgrade</a><ul> 763 <li>8.2.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 764 764 </ul> 765 765 </li> 766 <li>8. 4 <a href="#header.via">Via</a></li>766 <li>8.3 <a href="#header.via">Via</a></li> 767 767 </ul> 768 768 </li> … … 997 997 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 998 998 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 999 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8. 4</a>) header fields for both connections.999 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.3</a>) header fields for both connections. 1000 1000 </p> 1001 1001 <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 … … 1930 1930 except as noted above to replace a null path-absolute with "/" or "*". 1931 1931 </p> 1932 <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 1932 <div id="rfc.iref.h.10"></div> 1933 <div id="rfc.iref.h.11"></div> 1934 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.host" href="#header.host">Host</a></h2> 1935 <p id="rfc.section.5.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin 1936 server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the 1937 Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line. 1938 </p> 1939 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.80"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a> 1940 </pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then 1941 the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 1942 </p> 1943 <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 1944 <div id="rfc.figure.u.54"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 1945 Host: www.example.org 1946 </pre><p id="rfc.section.5.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information 1947 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.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, 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. When 1950 a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host. 1951 </p> 1952 <p id="rfc.section.5.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to 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 header field value for redirecting requests to internal servers, or for use as a cache key in a shared 1955 cache, 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.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request 1958 message that contains more than one Host header field or a Host header field with an invalid field-value. 1959 </p> 1960 <p id="rfc.section.5.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.5</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. 1961 </p> 1962 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> 1963 <p id="rfc.section.5.5.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header 1934 1964 field. 1935 1965 </p> 1936 <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 or1966 <p id="rfc.section.5.5.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.) 1967 </p> 1968 <p id="rfc.section.5.5.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or 1939 1969 vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request: 1940 1970 </p> … … 1948 1978 </li> 1949 1979 </ol> 1950 <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 determine1980 <p id="rfc.section.5.5.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 1951 1981 what exact resource is being requested. 1952 1982 </p> 1953 1983 <div id="rfc.iref.e.1"></div> 1954 1984 <div id="rfc.iref.t.7"></div> 1955 <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 connection1985 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 1986 <p id="rfc.section.5.6.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 1957 1987 context. The result of this process is called the "effective request URI". The "target resource" is the resource identified 1958 1988 by the effective request URI. 1959 1989 </p> 1960 <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 effective1990 <p id="rfc.section.5.6.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p> 1991 <p id="rfc.section.5.6.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective 1962 1992 request URI is constructed by concatenating 1963 1993 </p> 1964 <p id="rfc.section.5. 5.p.4"> </p>1994 <p id="rfc.section.5.6.p.4"> </p> 1965 1995 <ul> 1966 1996 <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured … … 1968 1998 </li> 1969 1999 <li>the octet sequence "://",</li> 1970 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8.2</a>), and2000 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 5.4</a>), and 1971 2001 </li> 1972 2002 <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li> 1973 2003 </ul> 1974 <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 effective2004 <p id="rfc.section.5.6.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 1975 2005 request URI is undefined. 1976 2006 </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>1978 <div id="rfc.figure.u.5 3"></div>2007 <p id="rfc.section.5.6.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 2008 <div id="rfc.figure.u.55"></div> 1979 2009 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1980 2010 Host: www.example.org:8080 … … 1982 2012 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 1983 2013 </p> 1984 <div id="rfc.figure.u.5 4"></div>2014 <div id="rfc.figure.u.56"></div> 1985 2015 <p>Example 2: the effective request URI for the message</p> <pre class="text">OPTIONS * HTTP/1.1 1986 2016 Host: www.example.org … … 1988 2018 thus "https://www.example.org". 1989 2019 </p> 1990 <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 response2020 <p id="rfc.section.5.6.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 "/". 2021 </p> 2022 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 2023 <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1994 2024 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1995 2025 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 1996 2026 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 2027 </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.2028 <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response. 1999 2029 </p> 2000 2030 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connections" href="#connections">Connections</a></h1> … … 2263 2293 <tr> 2264 2294 <td class="left">Host</td> 2265 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8.2</a></td>2295 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 5.4</a></td> 2266 2296 </tr> 2267 2297 <tr> … … 2279 2309 <tr> 2280 2310 <td class="left">Upgrade</td> 2281 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8. 3</a></td>2311 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.2</a></td> 2282 2312 </tr> 2283 2313 <tr> 2284 2314 <td class="left">Via</td> 2285 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8. 4</a></td>2315 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8.3</a></td> 2286 2316 </tr> 2287 2317 </tbody> … … 2289 2319 </div> 2290 2320 <div id="rfc.iref.c.13"></div> 2291 <div id="rfc.iref.h.1 0"></div>2321 <div id="rfc.iref.h.12"></div> 2292 2322 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 2293 2323 <p id="rfc.section.8.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such … … 2299 2329 </p> 2300 2330 <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p> 2301 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a>2331 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2302 2332 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 2303 2333 </pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove … … 2322 2352 of the response. For example, 2323 2353 </p> 2324 <div id="rfc.figure.u.5 6"></div><pre class="text"> Connection: close2354 <div id="rfc.figure.u.58"></div><pre class="text"> Connection: close 2325 2355 </pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>) after the current request/response is complete. 2326 2356 </p> … … 2328 2358 </p> 2329 2359 <p id="rfc.section.8.1.p.12">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code. 2330 </p>2331 <div id="rfc.iref.h.11"></div>2332 <div id="rfc.iref.h.12"></div>2333 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.host" href="#header.host">Host</a></h2>2334 <p id="rfc.section.8.2.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin2335 server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the2336 Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line.2337 </p>2338 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.82"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>2339 </pre><p id="rfc.section.8.2.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then2340 the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.2341 </p>2342 <p id="rfc.section.8.2.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p>2343 <div id="rfc.figure.u.58"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12344 Host: www.example.org2345 </pre><p id="rfc.section.8.2.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information2346 to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.2347 </p>2348 <p id="rfc.section.8.2.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, 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. When2349 a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host.2350 </p>2351 <p id="rfc.section.8.2.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to2352 poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it2353 relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared2354 cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.2355 </p>2356 <p id="rfc.section.8.2.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request2357 message that contains more than one Host header field or a Host header field with an invalid field-value.2358 </p>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.2360 2360 </p> 2361 2361 <div id="rfc.iref.u.5"></div> 2362 2362 <div id="rfc.iref.h.13"></div> 2363 <h2 id="rfc.section.8. 3"><a href="#rfc.section.8.3">8.3</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>2364 <p id="rfc.section.8. 3.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the2363 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2364 <p id="rfc.section.8.2.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the 2365 2365 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2366 2366 </p> … … 2370 2370 <a href="#header.upgrade" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2371 2371 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2372 </pre><p id="rfc.section.8. 3.p.3">For example,</p>2372 </pre><p id="rfc.section.8.2.p.3">For example,</p> 2373 2373 <div id="rfc.figure.u.60"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2374 </pre><p id="rfc.section.8. 3.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible2374 </pre><p id="rfc.section.8.2.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2375 2375 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2376 2376 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2379 2379 the server, possibly according to the nature of the request method or target resource). 2380 2380 </p> 2381 <p id="rfc.section.8. 3.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.2381 <p id="rfc.section.8.2.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. 2382 2382 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2383 2383 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 2384 2384 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2385 2385 </p> 2386 <p id="rfc.section.8. 3.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2387 </p> 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, it2386 <p id="rfc.section.8.2.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2387 </p> 2388 <p id="rfc.section.8.2.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2389 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>). 2390 2390 </p> 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 switched2391 <p id="rfc.section.8.2.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 2392 2392 to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. 2393 2393 </p> 2394 <p id="rfc.section.8. 3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2394 <p id="rfc.section.8.2.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2395 2395 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2396 2396 below. 2397 2397 </p> 2398 <h3 id="rfc.section.8. 3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>2399 <p id="rfc.section.8. 3.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade2398 <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3> 2399 <p id="rfc.section.8.2.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade 2400 2400 header field. Each registered protocol-name is associated with contact information and an optional set of specifications that 2401 2401 details how the connection will be processed after it has been upgraded. 2402 2402 </p> 2403 <p id="rfc.section.8. 3.1.p.2">Registrations 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.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules:2403 <p id="rfc.section.8.2.1.p.2">Registrations 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.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules: 2404 2404 </p> 2405 2405 <ol> … … 2421 2421 <div id="rfc.iref.v.1"></div> 2422 2422 <div id="rfc.iref.h.14"></div> 2423 <h2 id="rfc.section.8. 4"><a href="#rfc.section.8.4">8.4</a> <a id="header.via" href="#header.via">Via</a></h2>2424 <p id="rfc.section.8. 4.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server2423 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.via" href="#header.via">Via</a></h2> 2424 <p id="rfc.section.8.3.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server 2425 2425 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email 2426 2426 systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities … … 2432 2432 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 2433 2433 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 2434 </pre><p id="rfc.section.8. 4.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of2434 </pre><p id="rfc.section.8.3.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of 2435 2435 the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded 2436 2436 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 2437 2437 </p> 2438 <p id="rfc.section.8. 4.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port2438 <p id="rfc.section.8.3.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port 2439 2439 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 2440 2440 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 2441 2441 </p> 2442 <p id="rfc.section.8. 4.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.2443 </p> 2444 <p id="rfc.section.8. 4.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header2442 <p id="rfc.section.8.3.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 2443 </p> 2444 <p id="rfc.section.8.3.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header 2445 2445 fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 2446 2446 </p> 2447 <p id="rfc.section.8. 4.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses2447 <p id="rfc.section.8.3.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses 2448 2448 HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin 2449 2449 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2450 2450 </p> 2451 2451 <div id="rfc.figure.u.62"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2452 </pre><p id="rfc.section.8. 4.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,2452 </pre><p id="rfc.section.8.3.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, 2453 2453 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 2454 2454 </p> 2455 <p id="rfc.section.8. 4.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.2455 <p id="rfc.section.8.3.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. 2456 2456 For example, 2457 2457 </p> 2458 2458 <div id="rfc.figure.u.63"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2459 </pre><p id="rfc.section.8. 4.p.12">could be collapsed to</p>2459 </pre><p id="rfc.section.8.3.p.12">could be collapsed to</p> 2460 2460 <div id="rfc.figure.u.64"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2461 </pre><p id="rfc.section.8. 4.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced2461 </pre><p id="rfc.section.8.3.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 2462 2462 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 2463 2463 </p> … … 2496 2496 <td class="left">http</td> 2497 2497 <td class="left">standard</td> 2498 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 8.2</a>2498 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 5.4</a> 2499 2499 </td> 2500 2500 </tr> … … 2524 2524 <td class="left">http</td> 2525 2525 <td class="left">standard</td> 2526 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 8. 3</a>2526 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 8.2</a> 2527 2527 </td> 2528 2528 </tr> … … 2531 2531 <td class="left">http</td> 2532 2532 <td class="left">standard</td> 2533 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 8. 4</a>2533 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 8.3</a> 2534 2534 </td> 2535 2535 </tr> … … 2724 2724 </div> 2725 2725 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2> 2726 <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — 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> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8. 3.1</a> of this document.2726 <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — 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> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.2.1</a> of this document. 2727 2727 </p> 2728 2728 <p id="rfc.section.9.5.p.2">The HTTP Upgrade Token Registry located at <<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>> shall be updated with the registration below: … … 3075 3075 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3076 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> 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.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 5.4</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. 3078 3078 </p> 3079 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 … … 3138 3138 <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section 8.1</a>) 3139 3139 </p> 3140 <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 8. 3</a>)3140 <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 8.2</a>) 3141 3141 </p> 3142 3142 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="changes.from.rfc.2817" href="#changes.from.rfc.2817">Changes from RFC 2817</a></h2> 3143 <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8. 3.1</a>)3143 <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.2.1</a>) 3144 3144 </p> 3145 3145 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3694 3694 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3695 3695 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3696 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.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.c.13"><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>3696 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.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.c.13"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.2</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> 3697 3697 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3698 3698 </ul> … … 3704 3704 </li> 3705 3705 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3706 <li>effective request URI <a href="#rfc.iref.e.1"><b>5. 5</b></a></li>3706 <li>effective request URI <a href="#rfc.iref.e.1"><b>5.6</b></a></li> 3707 3707 </ul> 3708 3708 </li> … … 3724 3724 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.62"><b>4.1</b></a></li> 3725 3725 <li><tt>comment</tt> <a href="#rfc.iref.g.49"><b>3.2.4</b></a></li> 3726 <li><tt>Connection</tt> <a href="#rfc.iref.g.8 0"><b>8.1</b></a></li>3727 <li><tt>connection-token</tt> <a href="#rfc.iref.g.8 1"><b>8.1</b></a></li>3726 <li><tt>Connection</tt> <a href="#rfc.iref.g.81"><b>8.1</b></a></li> 3727 <li><tt>connection-token</tt> <a href="#rfc.iref.g.82"><b>8.1</b></a></li> 3728 3728 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.54"><b>3.3.2</b></a></li> 3729 3729 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> … … 3740 3740 <li><tt>header-field</tt> <a href="#rfc.iref.g.33"><b>3.2</b></a></li> 3741 3741 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3742 <li><tt>Host</tt> <a href="#rfc.iref.g.8 2"><b>8.2</b></a></li>3742 <li><tt>Host</tt> <a href="#rfc.iref.g.80"><b>5.4</b></a></li> 3743 3743 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3744 3744 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.25"><b>3</b></a></li> … … 3757 3757 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3758 3758 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3759 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.86"><b>8. 4</b></a></li>3760 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.87"><b>8. 4</b></a></li>3761 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.89"><b>8. 4</b></a></li>3759 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.86"><b>8.3</b></a></li> 3760 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.87"><b>8.3</b></a></li> 3761 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.89"><b>8.3</b></a></li> 3762 3762 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.4</b></a></li> 3763 3763 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b>4.1</b></a></li> … … 3769 3769 <li><tt>qvalue</tt> <a href="#rfc.iref.g.78"><b>4.4.1</b></a></li> 3770 3770 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li> 3771 <li><tt>received-by</tt> <a href="#rfc.iref.g.88"><b>8. 4</b></a></li>3772 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.85"><b>8. 4</b></a></li>3771 <li><tt>received-by</tt> <a href="#rfc.iref.g.88"><b>8.3</b></a></li> 3772 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.85"><b>8.3</b></a></li> 3773 3773 <li><tt>request-line</tt> <a href="#rfc.iref.g.27"><b>3.1.1</b></a></li> 3774 3774 <li><tt>request-target</tt> <a href="#rfc.iref.g.29"><b>3.1.1.2</b></a></li> … … 3791 3791 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3792 3792 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3793 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.83"><b>8. 3</b></a></li>3793 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.83"><b>8.2</b></a></li> 3794 3794 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3795 3795 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3796 3796 <li><tt>value</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3797 3797 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3798 <li><tt>Via</tt> <a href="#rfc.iref.g.84"><b>8. 4</b></a></li>3798 <li><tt>Via</tt> <a href="#rfc.iref.g.84"><b>8.3</b></a></li> 3799 3799 <li><tt>word</tt> <a href="#rfc.iref.g.41"><b>3.2.4</b></a></li> 3800 3800 </ul> … … 3807 3807 <li>Header Fields 3808 3808 <ul> 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.1 0"><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>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.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.2</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> 3810 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> 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>3811 <li>Host <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.1">5.6</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3812 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> 3813 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> 3814 3814 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3815 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8. 3</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3816 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8. 4</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>3815 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.2</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3816 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.3</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3817 3817 </ul> 3818 3818 </li> 3819 3819 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3820 3820 <li>headers <a href="#rfc.iref.h.4">3</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>3821 <li>Host header field <a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.1">5.6</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3822 3822 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3823 3823 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3859 3859 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3860 3860 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 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>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.7</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.2</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> 3862 3862 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li> 3863 3863 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> … … 3865 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 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>3867 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.10">5.7</a>, <a href="#rfc.xref.Part2.16">6.2.3</a></li> 3868 3868 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.13">6.2.3</a></li> 3869 3869 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> 3870 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.17">8. 3</a></li>3870 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.17">8.2</a></li> 3871 3871 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.19">10.6</a></li> 3872 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> … … 3925 3925 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li> 3926 3926 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></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>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.6</a>, <a href="#RFC3986"><b>12.1</b></a><ul> 3928 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> 3929 3929 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.7</a></li> … … 3936 3936 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3937 3937 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</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>3938 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.6</a></li> 3939 3939 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2.7.3</a></li> 3940 3940 </ul> … … 3944 3944 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li> 3945 3945 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li> 3946 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8. 3.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>3947 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8. 3.1</a></li>3946 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul> 3947 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a></li> 3948 3948 </ul> 3949 3949 </li> … … 3952 3952 </ul> 3953 3953 </li> 3954 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8. 4</a>, <a href="#RFC5322"><b>12.2</b></a><ul>3955 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">8. 4</a></li>3954 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8.3</a>, <a href="#RFC5322"><b>12.2</b></a><ul> 3955 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">8.3</a></li> 3956 3956 </ul> 3957 3957 </li> … … 3967 3967 </li> 3968 3968 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3969 <li>target resource <a href="#rfc.iref.t.7"><b>5. 5</b></a></li>3969 <li>target resource <a href="#rfc.iref.t.7"><b>5.6</b></a></li> 3970 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> 3971 3971 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li> … … 3978 3978 </li> 3979 3979 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3980 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8. 3</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3980 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.2</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3981 3981 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3982 3982 <li>URI scheme … … 3991 3991 </li> 3992 3992 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3993 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8. 4</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>3993 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.3</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3994 3994 </ul> 3995 3995 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1575 r1576 2471 2471 </section> 2472 2472 2473 <section title="Host" anchor="header.host"> 2474 <iref primary="true" item="Host header field" x:for-anchor=""/> 2475 <iref primary="true" item="Header Fields" subitem="Host" x:for-anchor=""/> 2476 <x:anchor-alias value="Host"/> 2477 <t> 2478 The "Host" header field in a request provides the host and port 2479 information from the target resource's URI, enabling the origin 2480 server to distinguish between resources while servicing requests 2481 for multiple host names on a single IP address. Since the Host 2482 field-value is critical information for handling a request, it 2483 &SHOULD; be sent as the first header field following the request-line. 2484 </t> 2485 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/> 2486 <x:ref>Host</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/> 2487 </artwork></figure> 2488 <t> 2489 A client &MUST; send a Host header field in all HTTP/1.1 request 2490 messages. If the target resource's URI includes an authority 2491 component, then the Host field-value &MUST; be identical to that 2492 authority component after excluding any userinfo (<xref target="http.uri"/>). 2493 If the authority component is missing or undefined for the target 2494 resource's URI, then the Host header field &MUST; be sent with an 2495 empty field-value. 2496 </t> 2497 <t> 2498 For example, a GET request to the origin server for 2499 <http://www.example.org/pub/WWW/> would begin with: 2500 </t> 2501 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 2502 GET /pub/WWW/ HTTP/1.1 2503 Host: www.example.org 2504 </artwork></figure> 2505 <t> 2506 The Host header field &MUST; be sent in an HTTP/1.1 request even 2507 if the request-target is in the form of an absolute-URI, since this 2508 allows the Host information to be forwarded through ancient HTTP/1.0 2509 proxies that might not have implemented Host. 2510 </t> 2511 <t> 2512 When an HTTP/1.1 proxy receives a request with a request-target in 2513 the form of an absolute-URI, the proxy &MUST; ignore the received 2514 Host header field (if any) and instead replace it with the host 2515 information of the request-target. When a proxy forwards a request, 2516 it &MUST; generate the Host header field based on the received 2517 absolute-URI rather than the received Host. 2518 </t> 2519 <t> 2520 Since the Host header field acts as an application-level routing 2521 mechanism, it is a frequent target for malware seeking to poison 2522 a shared cache or redirect a request to an unintended server. 2523 An interception proxy is particularly vulnerable if it relies on 2524 the Host header field value for redirecting requests to internal 2525 servers, or for use as a cache key in a shared cache, without 2526 first verifying that the intercepted connection is targeting a 2527 valid IP address for that host. 2528 </t> 2529 <t> 2530 A server &MUST; respond with a 400 (Bad Request) status code to 2531 any HTTP/1.1 request message that lacks a Host header field and 2532 to any request message that contains more than one Host header field 2533 or a Host header field with an invalid field-value. 2534 </t> 2535 <t> 2536 See Sections <xref target="the.resource.identified.by.a.request" format="counter"/> 2537 and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/> 2538 for other requirements relating to Host. 2539 </t> 2540 </section> 2541 2473 2542 <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request"> 2474 2543 <t> … … 3230 3299 include the "close" connection option in every response message that 3231 3300 does not have a 1xx (Informational) status code. 3232 </t>3233 </section>3234 3235 <section title="Host" anchor="header.host">3236 <iref primary="true" item="Host header field" x:for-anchor=""/>3237 <iref primary="true" item="Header Fields" subitem="Host" x:for-anchor=""/>3238 <x:anchor-alias value="Host"/>3239 <t>3240 The "Host" header field in a request provides the host and port3241 information from the target resource's URI, enabling the origin3242 server to distinguish between resources while servicing requests3243 for multiple host names on a single IP address. Since the Host3244 field-value is critical information for handling a request, it3245 &SHOULD; be sent as the first header field following the request-line.3246 </t>3247 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>3248 <x:ref>Host</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/>3249 </artwork></figure>3250 <t>3251 A client &MUST; send a Host header field in all HTTP/1.1 request3252 messages. If the target resource's URI includes an authority3253 component, then the Host field-value &MUST; be identical to that3254 authority component after excluding any userinfo (<xref target="http.uri"/>).3255 If the authority component is missing or undefined for the target3256 resource's URI, then the Host header field &MUST; be sent with an3257 empty field-value.3258 </t>3259 <t>3260 For example, a GET request to the origin server for3261 <http://www.example.org/pub/WWW/> would begin with:3262 </t>3263 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" ">3264 GET /pub/WWW/ HTTP/1.13265 Host: www.example.org3266 </artwork></figure>3267 <t>3268 The Host header field &MUST; be sent in an HTTP/1.1 request even3269 if the request-target is in the form of an absolute-URI, since this3270 allows the Host information to be forwarded through ancient HTTP/1.03271 proxies that might not have implemented Host.3272 </t>3273 <t>3274 When an HTTP/1.1 proxy receives a request with a request-target in3275 the form of an absolute-URI, the proxy &MUST; ignore the received3276 Host header field (if any) and instead replace it with the host3277 information of the request-target. When a proxy forwards a request,3278 it &MUST; generate the Host header field based on the received3279 absolute-URI rather than the received Host.3280 </t>3281 <t>3282 Since the Host header field acts as an application-level routing3283 mechanism, it is a frequent target for malware seeking to poison3284 a shared cache or redirect a request to an unintended server.3285 An interception proxy is particularly vulnerable if it relies on3286 the Host header field value for redirecting requests to internal3287 servers, or for use as a cache key in a shared cache, without3288 first verifying that the intercepted connection is targeting a3289 valid IP address for that host.3290 </t>3291 <t>3292 A server &MUST; respond with a 400 (Bad Request) status code to3293 any HTTP/1.1 request message that lacks a Host header field and3294 to any request message that contains more than one Host header field3295 or a Host header field with an invalid field-value.3296 </t>3297 <t>3298 See Sections <xref target="the.resource.identified.by.a.request" format="counter"/>3299 and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>3300 for other requirements relating to Host.3301 3301 </t> 3302 3302 </section>
Note: See TracChangeset
for help on using the changeset viewer.