Ignore:
Timestamp:
Mar 11, 2012, 4:49:08 AM (7 years ago)
Author:
fielding@…
Message:

Finish work on message routing by cleaning up the process of determining
an effective request URI and removing the now redundant old stuff about
"The Resource Identified by a Request". Related to #222

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1581 r1582  
    711711               <li>5.3&nbsp;&nbsp;&nbsp;<a href="#request-target">Request Target</a></li>
    712712               <li>5.4&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    713                <li>5.5&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
    714                <li>5.6&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    715                <li>5.7&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     713               <li>5.5&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
     714               <li>5.6&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    716715            </ul>
    717716         </li>
     
    18521851      </p>
    18531852      <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1854          are defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the target resource, which a user agent would resolve to its absolute form in order
    1855          to obtain the target URI. The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers
    1856          are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
     1853         are defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
     1854         to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment
     1855         identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    18571856      </p>
    18581857      <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p>
     
    19641963         message that contains more than one Host header field or a Host header field with an invalid field-value.
    19651964      </p>
    1966       <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>
    1967       <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
    1968          field.
    1969       </p>
    1970       <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.)
    1971       </p>
    1972       <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
    1973          vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
    1974       </p>
    1975       <ol>
    1976          <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
    1977          </li>
    1978          <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the
    1979             Host header field value.
    1980          </li>
    1981          <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.
    1982          </li>
    1983       </ol>
    1984       <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
    1985          what exact resource is being requested.
    1986       </p>
    19871965      <div id="rfc.iref.e.1"></div>
    1988       <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>
    1989       <p id="rfc.section.5.6.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-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
    1990          context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
    1991          by the effective request URI.
    1992       </p>
    1993       <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>
    1994       <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
    1995          request URI is constructed by concatenating
    1996       </p>
    1997       <p id="rfc.section.5.6.p.4"> </p>
    1998       <ul>
    1999          <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured
    2000             TCP connection,
    2001          </li>
    2002          <li>the octet sequence "://",</li>
    2003          <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;5.4</a>), and
    2004          </li>
    2005          <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li>
    2006       </ul>
    2007       <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
    2008          request URI is undefined.
    2009       </p>
    2010       <p id="rfc.section.5.6.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
     1966      <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>
     1967      <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, Host,
     1968         and connection context, in order to identify the intended target resource and properly service the request. The URI derived
     1969         from this reconstruction process is referred to as the "effective request URI".
     1970      </p>
     1971      <p id="rfc.section.5.5.p.2">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the
     1972         effective request URI is constructed as follows.
     1973      </p>
     1974      <p id="rfc.section.5.5.p.3">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,
     1975         the scheme is "http".
     1976      </p>
     1977      <p id="rfc.section.5.5.p.4">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target.
     1978         Otherwise, if a Host header field is supplied with a non-empty field-value, then the authority component is the same as the
     1979         Host field-value. Otherwise, the authority component is the concatenation of the default hostname configured for the server,
     1980         a colon (":"), and the connection's incoming TCP port number in decimal form.
     1981      </p>
     1982      <p id="rfc.section.5.5.p.5">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component
     1983         is empty. Otherwise, the combined path and query component is the same as the request-target.
     1984      </p>
     1985      <p id="rfc.section.5.5.p.6">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating
     1986         the scheme, "://", authority, and combined path and query component.
     1987      </p>
    20111988      <div id="rfc.figure.u.55"></div>
    2012       <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
     1989      <p>Example 1: the following message received over an insecure TCP connection</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    20131990Host: www.example.org:8080
    2014 </pre>  <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus
    2015          the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
    2016       </p>
    2017       <div id="rfc.figure.u.56"></div>
    2018       <p>Example 2: the effective request URI for the message</p>  <pre class="text">OPTIONS * HTTP/1.1
     1991</pre> <div id="rfc.figure.u.56"></div>
     1992      <p>has an effective request URI of</p>  <pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html
     1993</pre> <div id="rfc.figure.u.57"></div>
     1994      <p>Example 2: the following message received over an SSL/TLS-secured TCP connection</p>  <pre class="text">OPTIONS * HTTP/1.1
    20191995Host: www.example.org
    2020 </pre>  <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org",
    2021          thus "https://www.example.org".
    2022       </p>
    2023       <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 "/".
    2024       </p>
    2025       <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>
    2026       <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
     1996</pre> <div id="rfc.figure.u.58"></div>
     1997      <p>has an effective request URI of</p>  <pre class="text">https://www.example.org
     1998</pre> <p id="rfc.section.5.5.p.11">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Host field-value and instead replace it with a configured server name when constructing the effective request URI.
     1999      </p>
     2000      <p id="rfc.section.5.5.p.12">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 guess
     2001         the effective request URI's authority component.
     2002      </p>
     2003      <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>
     2004      <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
    20272005         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    20282006         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    20292007         see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
    20302008      </p>
    2031       <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.
     2009      <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.
    20322010      </p>
    20332011      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
     
    22962274               <tr>
    22972275                  <td class="left">Host</td>
    2298                   <td class="left"><a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a></td>
     2276                  <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;5.4</a></td>
    22992277               </tr>
    23002278               <tr>
     
    23322310      </p>
    23332311      <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p>
    2334       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
     2312      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
    23352313  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    23362314</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
     
    23552333         of the response. For example,
    23562334      </p>
    2357       <div id="rfc.figure.u.58"></div><pre class="text">  Connection: close
     2335      <div id="rfc.figure.u.60"></div><pre class="text">  Connection: close
    23582336</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.
    23592337      </p>
     
    23682346         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    23692347      </p>
    2370       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.87"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
     2348      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.87"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
    23712349
    23722350  <a href="#header.upgrade" class="smpl">protocol</a>         = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>]
     
    23742352  <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    23752353</pre><p id="rfc.section.8.2.p.3">For example,</p>
    2376       <div id="rfc.figure.u.60"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     2354      <div id="rfc.figure.u.62"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    23772355</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
    23782356         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
     
    24302408         of all senders along the request/response chain.
    24312409      </p>
    2432       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
     2410      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    24332411                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    24342412  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
     
    24522430         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    24532431      </p>
    2454       <div id="rfc.figure.u.62"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2432      <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    24552433</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,
    24562434         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
     
    24592437         For example,
    24602438      </p>
    2461       <div id="rfc.figure.u.63"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2439      <div id="rfc.figure.u.65"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    24622440</pre><p id="rfc.section.8.3.p.12">could be collapsed to</p>
    2463       <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2441      <div id="rfc.figure.u.66"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    24642442</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
    24652443         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
     
    24992477                  <td class="left">http</td>
    25002478                  <td class="left">standard</td>
    2501                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;5.4</a>
     2479                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a>
    25022480                  </td>
    25032481               </tr>
     
    30783056      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30793057      <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>
    3080       <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.5" 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;5.3</a>) are among the most important changes defined by HTTP/1.1.
     3058      <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;5.3</a>) are among the most important changes defined by HTTP/1.1.
    30813059      </p>
    30823060      <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
     
    31473125      </p>
    31483126      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    3149       <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
     3127      <div id="rfc.figure.u.67"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    31503128
    31513129<a href="#header.connection" class="smpl">Connection</a> = *( "," OWS ) connection-token *( OWS "," [ OWS
     
    32663244
    32673245<a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string
    3268 </pre> <div id="rfc.figure.u.66"></div>
     3246</pre> <div id="rfc.figure.u.68"></div>
    32693247      <p>ABNF diagnostics:</p><pre class="inline">; Connection defined but not used
    32703248; Content-Length defined but not used
     
    37113689            </li>
    37123690            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    3713                   <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>5.6</b></a></li>
     3691                  <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>5.5</b></a></li>
    37143692               </ul>
    37153693            </li>
     
    38203798                        <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>
    38213799                        <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>
    3822                         <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">5.6</a>, <a href="#rfc.xref.header.host.3">8</a>, <a href="#rfc.xref.header.host.4">9.1</a>, <a href="#rfc.xref.header.host.5">A.1.1</a></li>
     3800                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></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>
    38233801                        <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>
    38243802                        <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>
     
    38303808                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    38313809                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3832                   <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">5.6</a>, <a href="#rfc.xref.header.host.3">8</a>, <a href="#rfc.xref.header.host.4">9.1</a>, <a href="#rfc.xref.header.host.5">A.1.1</a></li>
     3810                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.10"><b>5.4</b></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>
    38333811                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    38343812                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
     
    38713849            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38723850                  <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>
    3873                   <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</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</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.3</a>, <a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.12">6.1.2.2</a>, <a href="#rfc.xref.Part2.13">6.1.5</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">6.2.3</a>, <a href="#rfc.xref.Part2.18">8.2</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#rfc.xref.Part2.20">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3851                  <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</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</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.3</a>, <a href="#rfc.xref.Part2.11">5.6</a>, <a href="#rfc.xref.Part2.12">6.1.2.2</a>, <a href="#rfc.xref.Part2.13">6.1.5</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">6.2.3</a>, <a href="#rfc.xref.Part2.18">8.2</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#rfc.xref.Part2.20">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
    38743852                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1</a></li>
    38753853                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
     
    38783856                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">5.3</a></li>
    38793857                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.3</a></li>
    3880                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.17">6.2.3</a></li>
     3858                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">5.6</a>, <a href="#rfc.xref.Part2.17">6.2.3</a></li>
    38813859                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.2.3</a></li>
    38823860                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
     
    39393917                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li>
    39403918                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
    3941                   <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">5.1</a>, <a href="#rfc.xref.RFC3986.19">5.6</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
     3919                  <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">5.1</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
    39423920                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a></li>
    39433921                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
     
    39503928                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li>
    39513929                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li>
    3952                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.19">5.6</a></li>
     3930                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a></li>
    39533931                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li>
    39543932                     </ul>
Note: See TracChangeset for help on using the changeset viewer.