Changeset 1576


Ignore:
Timestamp:
Mar 10, 2012, 3:07:51 AM (8 years ago)
Author:
fielding@…
Message:

Move Host header field to Message Routing

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1575 r1576  
    718718               <li>5.2&nbsp;&nbsp;&nbsp;<a href="#connecting.inbound">Connecting Inbound</a></li>
    719719               <li>5.3&nbsp;&nbsp;&nbsp;<a href="#request-target-types">Types of Request Target</a></li>
    720                <li>5.4&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
    721                <li>5.5&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    722                <li>5.6&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     720               <li>5.4&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
     721               <li>5.5&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
     722               <li>5.6&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
     723               <li>5.7&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    723724            </ul>
    724725         </li>
    … …  
    759760         <li>8.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    760761               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    761                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    762                <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
    763                      <li>8.3.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
     762               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
     763                     <li>8.2.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    764764                  </ul>
    765765               </li>
    766                <li>8.4&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     766               <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    767767            </ul>
    768768         </li>
    … …  
    997997         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    998998         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&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;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&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.3</a>) header fields for both connections.
    10001000      </p>
    10011001      <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
    … …  
    19301930         except as noted above to replace a null path-absolute with "/" or "*".
    19311931      </p>
    1932       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<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>&nbsp;<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&nbsp;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&nbsp;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 &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
     1944      <div id="rfc.figure.u.54"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
     1945Host: 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>&nbsp;<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
    19341964         field.
    19351965      </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&nbsp;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
     1966      <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&nbsp;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
    19391969         vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
    19401970      </p>
    … …  
    19481978         </li>
    19491979      </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 determine
     1980      <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
    19511981         what exact resource is being requested.
    19521982      </p>
    19531983      <div id="rfc.iref.e.1"></div>
    19541984      <div id="rfc.iref.t.7"></div>
    1955       <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<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
     1985      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<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
    19571987         context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
    19581988         by the effective request URI.
    19591989      </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 effective
     1990      <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
    19621992         request URI is constructed by concatenating
    19631993      </p>
    1964       <p id="rfc.section.5.5.p.4"> </p>
     1994      <p id="rfc.section.5.6.p.4"> </p>
    19651995      <ul>
    19661996         <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured
    … …  
    19681998         </li>
    19691999         <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&nbsp;8.2</a>), and
     2000         <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;5.4</a>), and
    19712001         </li>
    19722002         <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li>
    19732003      </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 effective
     2004      <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
    19752005         request URI is undefined.
    19762006      </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.53"></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>
    19792009      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    19802010Host: www.example.org:8080
    … …  
    19822012         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
    19832013      </p>
    1984       <div id="rfc.figure.u.54"></div>
     2014      <div id="rfc.figure.u.56"></div>
    19852015      <p>Example 2: the effective request URI for the message</p>  <pre class="text">OPTIONS * HTTP/1.1
    19862016Host: www.example.org
    … …  
    19882018         thus "https://www.example.org".
    19892019      </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&nbsp;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>&nbsp;<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
     2020      <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&nbsp;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>&nbsp;<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
    19942024         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    19952025         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    19962026         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.
    19972027      </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.
    19992029      </p>
    20002030      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    … …  
    22632293               <tr>
    22642294                  <td class="left">Host</td>
    2265                   <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.2</a></td>
     2295                  <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;5.4</a></td>
    22662296               </tr>
    22672297               <tr>
    … …  
    22792309               <tr>
    22802310                  <td class="left">Upgrade</td>
    2281                   <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.3</a></td>
     2311                  <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.2</a></td>
    22822312               </tr>
    22832313               <tr>
    22842314                  <td class="left">Via</td>
    2285                   <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.4</a></td>
     2315                  <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.3</a></td>
    22862316               </tr>
    22872317            </tbody>
    … …  
    22892319      </div>
    22902320      <div id="rfc.iref.c.13"></div>
    2291       <div id="rfc.iref.h.10"></div>
     2321      <div id="rfc.iref.h.12"></div>
    22922322      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    22932323      <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
    … …  
    22992329      </p>
    23002330      <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.55"></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>
    23022332  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    23032333</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
    … …  
    23222352         of the response. For example,
    23232353      </p>
    2324       <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
     2354      <div id="rfc.figure.u.58"></div><pre class="text">  Connection: close
    23252355</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&nbsp;6.1</a>) after the current request/response is complete.
    23262356      </p>
    … …  
    23282358      </p>
    23292359      <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>&nbsp;<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 origin
    2335          server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the
    2336          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&nbsp;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, then
    2340          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&nbsp;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 &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    2343       <div id="rfc.figure.u.58"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    2344 Host: www.example.org
    2345 </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 information
    2346          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. When
    2349          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 to
    2352          poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
    2353          relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared
    2354          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 request
    2357          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.
    23602360      </p>
    23612361      <div id="rfc.iref.u.5"></div>
    23622362      <div id="rfc.iref.h.13"></div>
    2363       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<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 the
     2363      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<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
    23652365         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    23662366      </p>
    … …  
    23702370  <a href="#header.upgrade" class="smpl">protocol-name</a>    = <a href="#rule.token.separators" class="smpl">token</a>
    23712371  <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>
    23732373      <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, incompatible
     2374</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
    23752375         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    23762376         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    23792379         the server, possibly according to the nature of the request method or target resource).
    23802380      </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.
    23822382         Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    23832383         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
    23842384         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.
    23852385      </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&nbsp;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, it
     2386      <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&nbsp;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
    23892389         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>).
    23902390      </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 switched
     2391      <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
    23922392         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.
    23932393      </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 defined
     2394      <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
    23952395         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    23962396         below.
    23972397      </p>
    2398       <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<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 Upgrade
     2398      <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;<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
    24002400         header field. Each registered protocol-name is associated with contact information and an optional set of specifications that
    24012401         details how the connection will be processed after it has been upgraded.
    24022402      </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:
    24042404      </p>
    24052405      <ol>
    … …  
    24212421      <div id="rfc.iref.v.1"></div>
    24222422      <div id="rfc.iref.h.14"></div>
    2423       <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<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 server
     2423      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<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
    24252425         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
    24262426         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
    … …  
    24322432  <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>
    24332433  <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 of
     2434</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
    24352435         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    24362436         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    24372437      </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 port
     2438      <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
    24392439         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    24402440         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.
    24412441      </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 header
     2442      <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
    24452445         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.
    24462446      </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 uses
     2447      <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
    24482448         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
    24492449         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    24502450      </p>
    24512451      <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,
    24532453         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    24542454      </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.
    24562456         For example,
    24572457      </p>
    24582458      <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>
    24602460      <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 replaced
     2461</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
    24622462         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    24632463      </p>
    … …  
    24962496                  <td class="left">http</td>
    24972497                  <td class="left">standard</td>
    2498                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;8.2</a>
     2498                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a>
    24992499                  </td>
    25002500               </tr>
    … …  
    25242524                  <td class="left">http</td>
    25252525                  <td class="left">standard</td>
    2526                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.3</a>
     2526                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.2</a>
    25272527                  </td>
    25282528               </tr>
    … …  
    25312531                  <td class="left">http</td>
    25322532                  <td class="left">standard</td>
    2533                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.4</a>
     2533                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.3</a>
    25342534                  </td>
    25352535               </tr>
    … …  
    27242724      </div>
    27252725      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<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&nbsp;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&nbsp;8.2.1</a> of this document.
    27272727      </p>
    27282728      <p id="rfc.section.9.5.p.2">The HTTP Upgrade Token Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    … …  
    30753075      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30763076      <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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&nbsp;3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.
    30783078      </p>
    30793079      <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
    … …  
    31383138      <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&nbsp;8.1</a>)
    31393139      </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&nbsp;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&nbsp;8.2</a>)
    31413141      </p>
    31423142      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<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&nbsp;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&nbsp;8.2.1</a>)
    31443144      </p>
    31453145      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    36943694                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    36953695                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3696                   <li>Connection header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    36973697                  <li>Content-Length header field&nbsp;&nbsp;<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>
    36983698               </ul>
    … …  
    37043704            </li>
    37053705            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    3706                   <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>5.5</b></a></li>
     3706                  <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>5.6</b></a></li>
    37073707               </ul>
    37083708            </li>
    … …  
    37243724                        <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>4.1</b></a></li>
    37253725                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.4</b></a></li>
    3726                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>8.1</b></a></li>
    3727                         <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>8.1</b></a></li>
     3726                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>8.1</b></a></li>
     3727                        <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>8.1</b></a></li>
    37283728                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>3.3.2</b></a></li>
    37293729                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    … …  
    37403740                        <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>3.2</b></a></li>
    37413741                        <li>HEXDIG&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>1.2</b></a></li>
    3742                         <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>8.2</b></a></li>
     3742                        <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.4</b></a></li>
    37433743                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    37443744                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>3</b></a></li>
    … …  
    37573757                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    37583758                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    3759                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.4</b></a></li>
    3760                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.4</b></a></li>
    3761                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.4</b></a></li>
     3759                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.3</b></a></li>
     3760                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.3</b></a></li>
     3761                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.3</b></a></li>
    37623762                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.4</b></a></li>
    37633763                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>4.1</b></a></li>
    … …  
    37693769                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>4.4.1</b></a></li>
    37703770                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li>
    3771                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.4</b></a></li>
    3772                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.4</b></a></li>
     3771                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.3</b></a></li>
     3772                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.3</b></a></li>
    37733773                        <li><tt>request-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>3.1.1</b></a></li>
    37743774                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>3.1.1.2</b></a></li>
    … …  
    37913791                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    37923792                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    3793                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>8.3</b></a></li>
     3793                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>8.2</b></a></li>
    37943794                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    37953795                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    37963796                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>4</b></a></li>
    37973797                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3798                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.4</b></a></li>
     3798                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.3</b></a></li>
    37993799                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.4</b></a></li>
    38003800                     </ul>
    … …  
    38073807                  <li>Header Fields&nbsp;&nbsp;
    38083808                     <ul>
    3809                         <li>Connection&nbsp;&nbsp;<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>
     3809                        <li>Connection&nbsp;&nbsp;<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>
    38103810                        <li>Content-Length&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    38123812                        <li>TE&nbsp;&nbsp;<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>
    38133813                        <li>Trailer&nbsp;&nbsp;<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>
    38143814                        <li>Transfer-Encoding&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    38173817                     </ul>
    38183818                  </li>
    38193819                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    38203820                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3821                   <li>Host header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    38223822                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    38233823                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    … …  
    38593859            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38603860                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    3861                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    38623862                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
    38633863                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    … …  
    38653865                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">6.1.2.2</a>, <a href="#rfc.xref.Part2.12">6.1.5</a></li>
    38663866                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.3</a></li>
    3867                         <li><em>Section 7.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">5.7</a>, <a href="#rfc.xref.Part2.16">6.2.3</a></li>
    38683868                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a></li>
    38693869                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    3870                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">8.3</a></li>
     3870                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">8.2</a></li>
    38713871                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">10.6</a></li>
    38723872                        <li><em>Section 7.4.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.18">10.6</a></li>
    … …  
    39253925                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li>
    39263926                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
    3927                   <li><em>RFC3986</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    39283928                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">5.3</a></li>
    39293929                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
    … …  
    39363936                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li>
    39373937                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li>
    3938                         <li><em>Section 4.3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.6</a></li>
    39393939                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li>
    39403940                     </ul>
    … …  
    39443944                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li>
    39453945                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li>
    3946                   <li><em>RFC5226</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a></li>
    39483948                     </ul>
    39493949                  </li>
    … …  
    39523952                     </ul>
    39533953                  </li>
    3954                   <li><em>RFC5322</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">8.4</a></li>
     3954                  <li><em>RFC5322</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">8.3</a></li>
    39563956                     </ul>
    39573957                  </li>
    … …  
    39673967            </li>
    39683968            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    3969                   <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.5</b></a></li>
     3969                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.6</b></a></li>
    39703970                  <li>TE header field&nbsp;&nbsp;<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>
    39713971                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li>
    … …  
    39783978            </li>
    39793979            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3980                   <li>Upgrade header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    39813981                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    39823982                  <li>URI scheme&nbsp;&nbsp;
    … …  
    39913991            </li>
    39923992            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3993                   <li>Via header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    39943994               </ul>
    39953995            </li>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1575 r1576  
    24712471</section>
    24722472
     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   &lt;http://www.example.org/pub/WWW/&gt; would begin with:
     2500</t>
     2501<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2502GET /pub/WWW/ HTTP/1.1
     2503Host: 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
    24732542<section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
    24742543<t>
    … …  
    32303299   include the "close" connection option in every response message that
    32313300   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 port
    3241    information from the target resource's URI, enabling the origin
    3242    server to distinguish between resources while servicing requests
    3243    for multiple host names on a single IP address.  Since the Host
    3244    field-value is critical information for handling a request, it
    3245    &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 request
    3252    messages.  If the target resource's URI includes an authority
    3253    component, then the Host field-value &MUST; be identical to that
    3254    authority component after excluding any userinfo (<xref target="http.uri"/>).
    3255    If the authority component is missing or undefined for the target
    3256    resource's URI, then the Host header field &MUST; be sent with an
    3257    empty field-value.
    3258 </t>
    3259 <t>
    3260    For example, a GET request to the origin server for
    3261    &lt;http://www.example.org/pub/WWW/&gt; would begin with:
    3262 </t>
    3263 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    3264 GET /pub/WWW/ HTTP/1.1
    3265 Host: www.example.org
    3266 </artwork></figure>
    3267 <t>
    3268    The Host header field &MUST; be sent in an HTTP/1.1 request even
    3269    if the request-target is in the form of an absolute-URI, since this
    3270    allows the Host information to be forwarded through ancient HTTP/1.0
    3271    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 in
    3275    the form of an absolute-URI, the proxy &MUST; ignore the received
    3276    Host header field (if any) and instead replace it with the host
    3277    information of the request-target.  When a proxy forwards a request,
    3278    it &MUST; generate the Host header field based on the received
    3279    absolute-URI rather than the received Host.
    3280 </t>
    3281 <t>
    3282    Since the Host header field acts as an application-level routing
    3283    mechanism, it is a frequent target for malware seeking to poison
    3284    a shared cache or redirect a request to an unintended server.
    3285    An interception proxy is particularly vulnerable if it relies on
    3286    the Host header field value for redirecting requests to internal
    3287    servers, or for use as a cache key in a shared cache, without
    3288    first verifying that the intercepted connection is targeting a
    3289    valid IP address for that host.
    3290 </t>
    3291 <t>
    3292    A server &MUST; respond with a 400 (Bad Request) status code to
    3293    any HTTP/1.1 request message that lacks a Host header field and
    3294    to any request message that contains more than one Host header field
    3295    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.
    33013301</t>
    33023302</section>
Note: See TracChangeset for help on using the changeset viewer.