Changeset 1575


Ignore:
Timestamp:
Mar 10, 2012, 2:57:18 AM (7 years ago)
Author:
fielding@…
Message:

Explain first half of message routing. Related to #218.

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

Legend:

Unmodified
Added
Removed

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

    r1574 r1575  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 10, 2012";
     462       content: "Expires September 11, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    510510      <meta name="dct.creator" content="Reschke, J. F.">
    511511      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    512       <meta name="dct.issued" scheme="ISO8601" content="2012-03-09">
     512      <meta name="dct.issued" scheme="ISO8601" content="2012-03-10">
    513513      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    542542            </tr>
    543543            <tr>
    544                <td class="left">Expires: September 10, 2012</td>
     544               <td class="left">Expires: September 11, 2012</td>
    545545               <td class="right">HP</td>
    546546            </tr>
    … …  
    595595            <tr>
    596596               <td class="left"></td>
    597                <td class="right">March 9, 2012</td>
     597               <td class="right">March 10, 2012</td>
    598598            </tr>
    599599         </tbody>
    … …  
    628628         in progress”.
    629629      </p>
    630       <p>This Internet-Draft will expire on September 10, 2012.</p>
     630      <p>This Internet-Draft will expire on September 11, 2012.</p>
    631631      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    632632      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    670670                     <li>3.1.1&nbsp;&nbsp;&nbsp;<a href="#request.line">Request Line</a><ul>
    671671                           <li>3.1.1.1&nbsp;&nbsp;&nbsp;<a href="#method">Method</a></li>
    672                            <li>3.1.1.2&nbsp;&nbsp;&nbsp;<a href="#request-target">request-target</a></li>
     672                           <li>3.1.1.2&nbsp;&nbsp;&nbsp;<a href="#request-target">Request Target</a></li>
    673673                        </ul>
    674674                     </li>
    … …  
    715715         </li>
    716716         <li>5.&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul>
    717                <li>5.1&nbsp;&nbsp;&nbsp;<a href="#request-target-types">Types of Request Target</a></li>
    718                <li>5.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
    719                <li>5.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    720                <li>5.4&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     717               <li>5.1&nbsp;&nbsp;&nbsp;<a href="#target-resource">Identifying a Target Resource</a></li>
     718               <li>5.2&nbsp;&nbsp;&nbsp;<a href="#connecting.inbound">Connecting Inbound</a></li>
     719               <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>
    721723            </ul>
    722724         </li>
    … …  
    12501252</pre><p id="rfc.section.3.1.1.1.p.3">The methods defined by this specification can be found in <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    12511253      </p>
    1252       <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h4>
     1254      <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a>&nbsp;<a id="request-target" href="#request-target">Request Target</a></h4>
    12531255      <p id="rfc.section.3.1.1.2.p.1">The request-target identifies the target resource upon which to apply the request. The four options for request-target are
    1254          described in <a href="#request-target-types" title="Types of Request Target">Section&nbsp;5.1</a>.
     1256         described in <a href="#request-target-types" title="Types of Request Target">Section&nbsp;5.3</a>.
    12551257      </p>
    12561258      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
    … …  
    18421844      </ul>
    18431845      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
    1844       <p id="rfc.section.5.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target
    1845          resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target.
    1846       </p>
    1847       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2>
    1848       <p id="rfc.section.5.1.p.1">The proper format choice of the four options available to request-target depends on the method being requested and if the
    1849          request is being made to a proxy.
     1846      <p id="rfc.section.5.p.1">HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration,
     1847         and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain
     1848         back to the client.
     1849      </p>
     1850      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="target-resource" href="#target-resource">Identifying a Target Resource</a></h2>
     1851      <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases,
     1852         communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification
     1853         mechanism and configuration techniques as general-purpose Web browsers.
     1854      </p>
     1855      <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
     1856         are defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&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
     1857         to obtain the target URI. The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers
     1858         are for client-side processing only.
     1859      </p>
     1860      <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p>
     1861      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="connecting.inbound" href="#connecting.inbound">Connecting Inbound</a></h2>
     1862      <p id="rfc.section.5.2.p.1">Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired
     1863         semantics and, if so, where that request is to be directed.
     1864      </p>
     1865      <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), then the request is usually directed to the cache first.
     1866      </p>
     1867      <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy
     1868         is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching,
     1869         selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy
     1870         is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy.
     1871      </p>
     1872      <p id="rfc.section.5.2.p.4">If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to
     1873         connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and
     1874         defined by its associated specification, similar to how this specification defines origin server access for resolution of
     1875         the "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) schemes.
     1876      </p>
     1877      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2>
     1878      <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target (<a href="#request-target" title="Request Target">Section&nbsp;3.1.1.2</a>), depending on both the method being requested and whether the request is to a proxy.
    18501879      </p>
    18511880      <div id="origin-form">
    1852          <p id="rfc.section.5.1.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a
     1881         <p id="rfc.section.5.3.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a
    18531882            resource identified by an "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) URI. In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target and the authority component (excluding any userinfo) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource identified
    18541883            as
    … …  
    18561885      </div>
    18571886      <div id="rfc.figure.u.46"></div><pre>http://www.example.org/where?q=now
    1858 </pre><p id="rfc.section.5.1.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the
     1887</pre><p id="rfc.section.5.3.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the
    18591888         lines:
    18601889      </p>
    18611890      <div id="rfc.figure.u.47"></div><pre class="text2">GET /where?q=now HTTP/1.1
    18621891Host: www.example.org
    1863 </pre><p id="rfc.section.5.1.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.
     1892</pre><p id="rfc.section.5.3.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.
    18641893         If the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target.
    18651894      </p>
    1866       <p id="rfc.section.5.1.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
     1895      <p id="rfc.section.5.3.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
    18671896      </p>
    18681897      <div id="absolute-URI-form">
    1869          <p id="rfc.section.5.1.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
     1898         <p id="rfc.section.5.3.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
    18701899            cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
    18711900            loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
    … …  
    18741903      </div>
    18751904      <div id="rfc.figure.u.48"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1876 </pre><p id="rfc.section.5.1.p.10">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    1877       </p>
    1878       <p id="rfc.section.5.1.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
     1905</pre><p id="rfc.section.5.3.p.10">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
     1906      </p>
     1907      <p id="rfc.section.5.3.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    18791908      </p>
    18801909      <div id="authority-form">
    1881          <p id="rfc.section.5.1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,
     1910         <p id="rfc.section.5.3.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,
    18821911         </p>
    18831912      </div>
    18841913      <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    18851914</pre><div id="asterix-form">
    1886          <p id="rfc.section.5.1.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening
     1915         <p id="rfc.section.5.3.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening
    18871916            process) rather than to a specific named resource at that server. For example,
    18881917         </p>
    18891918      </div>
    18901919      <div id="rfc.figure.u.50"></div><pre class="text2">OPTIONS * HTTP/1.1
    1891 </pre><p id="rfc.section.5.1.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
     1920</pre><p id="rfc.section.5.3.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
    18921921         no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server.
    18931922      </p>
    … …  
    18981927Host: www.example.org:8001
    18991928</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
    1900       <p id="rfc.section.5.1.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
     1929      <p id="rfc.section.5.3.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
    19011930         except as noted above to replace a null path-absolute with "/" or "*".
    19021931      </p>
    1903       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</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>
    1904       <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header
     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
    19051934         field.
    19061935      </p>
    1907       <p id="rfc.section.5.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix&nbsp;A.1.1</a> for other requirements on Host support in HTTP/1.1.)
    1908       </p>
    1909       <p id="rfc.section.5.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or
     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
    19101939         vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
    19111940      </p>
    … …  
    19191948         </li>
    19201949      </ol>
    1921       <p id="rfc.section.5.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine
     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
    19221951         what exact resource is being requested.
    19231952      </p>
    19241953      <div id="rfc.iref.e.1"></div>
    19251954      <div id="rfc.iref.t.7"></div>
    1926       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2>
    1927       <p id="rfc.section.5.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection
     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
    19281957         context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
    19291958         by the effective request URI.
    19301959      </p>
    1931       <p id="rfc.section.5.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p>
    1932       <p id="rfc.section.5.3.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective
     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
    19331962         request URI is constructed by concatenating
    19341963      </p>
    1935       <p id="rfc.section.5.3.p.4"> </p>
     1964      <p id="rfc.section.5.5.p.4"> </p>
    19361965      <ul>
    19371966         <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured
    … …  
    19431972         <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li>
    19441973      </ul>
    1945       <p id="rfc.section.5.3.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective
     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
    19461975         request URI is undefined.
    19471976      </p>
    1948       <p id="rfc.section.5.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
     1977      <p id="rfc.section.5.5.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
    19491978      <div id="rfc.figure.u.53"></div>
    19501979      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    … …  
    19591988         thus "https://www.example.org".
    19601989      </p>
    1961       <p id="rfc.section.5.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&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 "/".
    1962       </p>
    1963       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    1964       <p id="rfc.section.5.4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
     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
    19651994         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    19661995         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    1967          see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
    1968       </p>
    1969       <p id="rfc.section.5.4.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.
     1996         see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
     1997      </p>
     1998      <p id="rfc.section.5.6.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.
    19701999      </p>
    19712000      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    … …  
    20232052      <p id="rfc.section.6.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    20242053      </p>
    2025       <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2054      <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    20262055         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    20272056      </p>
    … …  
    20862115         <li>Content-Type</li>
    20872116      </ul>
    2088       <p id="rfc.section.6.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     2117      <p id="rfc.section.6.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    20892118      </p>
    20902119      <div class="note" id="rfc.section.6.1.3.2.p.7">
    … …  
    21222151      <h3 id="rfc.section.6.1.5"><a href="#rfc.section.6.1.5">6.1.5</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    21232152      <p id="rfc.section.6.1.5.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2124          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     2153         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    21252154         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    21262155      </p>
    … …  
    21352164      </p>
    21362165      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2137       <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2166      <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    21382167         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21392168         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    21422171      <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21432172      <ul>
    2144          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2145          </li>
    2146          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     2173         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2174         </li>
     2175         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    21472176         </li>
    21482177      </ul>
    … …  
    21882217         <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    21892218            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    2190             1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2219            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    21912220         </li>
    21922221      </ul>
    … …  
    22772306      </p>
    22782307      <p id="rfc.section.8.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
    2279          in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     2308         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    22802309      </p>
    22812310      <p id="rfc.section.8.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
    … …  
    23282357         message that contains more than one Host header field or a Host header field with an invalid field-value.
    23292358      </p>
    2330       <p id="rfc.section.8.2.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
     2359      <p id="rfc.section.8.2.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.4</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
    23312360      </p>
    23322361      <div id="rfc.iref.u.5"></div>
    … …  
    23582387      </p>
    23592388      <p id="rfc.section.8.3.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2360          is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2389         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    23612390      </p>
    23622391      <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
    … …  
    27752804         a Denial of Service against implementations that accept fields with unlimited lengths.
    27762805      </p>
    2777       <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
     2806      <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title="Request Target">Section&nbsp;3.1.1.2</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
    27782807         that most implementations will choose substantially higher limits.
    27792808      </p>
    2780       <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2809      <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    27812810      </p>
    27822811      <p id="rfc.section.10.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
    … …  
    30463075      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30473076      <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>
    3048       <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&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;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.
    30493078      </p>
    30503079      <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
    … …  
    30783107      </p>
    30793108      <p id="rfc.section.A.2.p.2">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    3080          form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>)
     3109         form is allowed for the OPTIONS request method only. (<a href="#request-target" title="Request Target">Section&nbsp;3.1.1.2</a>)
    30813110      </p>
    30823111      <p id="rfc.section.A.2.p.3">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
    … …  
    36383667         <ul class="ind">
    36393668            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    3640                   <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.1</a></li>
     3669                  <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.3</a></li>
    36413670                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
    36423671                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>9.3.2</b></a></li>
    3643                   <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.1</a></li>
    3644                   <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">5.1</a></li>
     3672                  <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.3</a></li>
     3673                  <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">5.3</a></li>
    36453674               </ul>
    36463675            </li>
    … …  
    36753704            </li>
    36763705            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    3677                   <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>5.3</b></a></li>
     3706                  <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>5.5</b></a></li>
    36783707               </ul>
    36793708            </li>
    … …  
    37803809                        <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>
    37813810                        <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>
    3782                         <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.12"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3811                        <li>Host&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>
    37833812                        <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>
    37843813                        <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>
    … …  
    37903819                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    37913820                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3792                   <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.11"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3821                  <li>Host header field&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>
    37933822                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    37943823                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    … …  
    38233852            </li>
    38243853            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    3825                   <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">5.1</a></li>
     3854                  <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">5.3</a></li>
    38263855                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
    38273856                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
    … …  
    38303859            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38313860                  <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>
    3832                   <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.4</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.3</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3861                  <li><em>Part2</em>&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>
    38333862                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
    38343863                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    38353864                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
    3836                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a></li>
    3837                         <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">5.1</a></li>
    3838                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.4</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>
    3839                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a></li>
     3865                        <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>
     3866                        <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>
     3868                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a></li>
    38403869                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    3841                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">8.3</a></li>
    3842                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">10.6</a></li>
    3843                         <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.17">10.6</a></li>
     3870                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">8.3</a></li>
     3871                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">10.6</a></li>
     3872                        <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>
    38443873                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
    3845                         <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li>
     3874                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>
    38463875                     </ul>
    38473876                  </li>
    … …  
    38523881                     </ul>
    38533882                  </li>
    3854                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a>, <a href="#rfc.xref.Part6.6">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
     3883                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">6.1.3.2</a>, <a href="#rfc.xref.Part6.7">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
    38553884                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
    38563885                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    3857                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">8.1</a></li>
    3858                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a></li>
     3886                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.7">8.1</a></li>
     3887                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.6">6.1.3.2</a></li>
    38593888                     </ul>
    38603889                  </li>
    … …  
    38963925                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li>
    38973926                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
    3898                   <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.1</a>, <a href="#rfc.xref.RFC3986.20">5.3</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
    3899                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">5.1</a></li>
     3927                  <li><em>RFC3986</em>&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>
     3928                        <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>
    39003929                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
    39013930                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.7.1</a></li>
    … …  
    39073936                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li>
    39083937                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li>
    3909                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.3</a></li>
     3938                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.5</a></li>
    39103939                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li>
    39113940                     </ul>
    … …  
    39383967            </li>
    39393968            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    3940                   <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.3</b></a></li>
     3969                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.5</b></a></li>
    39413970                  <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>
    39423971                  <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>

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

    r1574 r1575  
    11361136</section>
    11371137
    1138 <section title="request-target" anchor="request-target">
     1138<section title="Request Target" anchor="request-target">
    11391139  <x:anchor-alias value="request-target"/>
    11401140<t>
    … …  
    22952295<section title="Message Routing" anchor="message.routing">
    22962296<t>
    2297    In most cases, the user agent is provided a URI reference
    2298    from which it determines an absolute URI for identifying the target
    2299    resource.  When a request to the resource is initiated, all or part
    2300    of that URI is used to construct the HTTP request-target.
    2301 </t>
     2297   HTTP request message routing is determined by each client based on the
     2298   target resource, the client's proxy configuration, and
     2299   establishment or reuse of an inbound connection.  The corresponding
     2300   response routing follows the same connection chain back to the client.
     2301</t>
     2302
     2303<section title="Identifying a Target Resource" anchor="target-resource">
     2304<t>
     2305   HTTP is used in a wide variety of applications, ranging from
     2306   general-purpose computers to home appliances.  In some cases,
     2307   communication options are hard-coded in a client's configuration.
     2308   However, most HTTP clients rely on the same resource identification
     2309   mechanism and configuration techniques as general-purpose Web browsers.
     2310</t>
     2311<t>
     2312   HTTP communication is initiated by a user agent for some purpose.
     2313   The purpose is a combination of request semantics, which are defined in
     2314   <xref target="Part2"/>, and a target resource upon which to apply those
     2315   semantics.  A URI reference (<xref target="uri"/>) is typically used as
     2316   an identifier for the target resource, which a user agent would resolve to
     2317   its absolute form in order to obtain the target URI.  The target URI
     2318   excludes the reference's fragment identifier component, if any,
     2319   since fragment identifiers are for client-side processing only.
     2320</t>
     2321<t>
     2322   HTTP intermediaries obtain the request semantics and target URI
     2323   from the request-line of an incoming request message.
     2324</t>
     2325</section>
     2326
     2327<section title="Connecting Inbound" anchor="connecting.inbound">
     2328<t>
     2329   Once the target URI is determined, a client needs to decide whether
     2330   a network request is necessary to accomplish the desired semantics and,
     2331   if so, where that request is to be directed.
     2332</t>
     2333<t>
     2334   If the client has a response cache and the request semantics can be
     2335   satisfied by a cache (<xref target="Part6"/>), then the request is
     2336   usually directed to the cache first.
     2337</t>
     2338<t>
     2339   If the request is not satisfied by a cache, then a typical client will
     2340   check its configuration to determine whether a proxy is to be used to
     2341   satisfy the request.  Proxy configuration is implementation-dependent,
     2342   but is often based on URI prefix matching, selective authority matching,
     2343   or both, and the proxy itself is usually identified by an "http" or
     2344   "https" URI.  If a proxy is applicable, the client connects inbound by
     2345   establishing (or reusing) a connection to that proxy.
     2346</t>
     2347<t>
     2348   If no proxy is applicable, a typical client will invoke a handler routine,
     2349   usually specific to the target URI's scheme, to connect directly
     2350   to an authority for the target resource.  How that is accomplished is
     2351   dependent on the target URI scheme and defined by its associated
     2352   specification, similar to how this specification defines origin server
     2353   access for resolution of the "http" (<xref target="http.uri"/>) and
     2354   "https" (<xref target="https.uri"/>) schemes.
     2355</t>
     2356</section>
    23022357
    23032358<section title="Types of Request Target" anchor="request-target-types">
    23042359<t>
    2305    The proper format choice of the four options available to request-target
    2306    depends on the method being requested and if the request is being made to
    2307    a proxy.
     2360   Once an inbound connection is obtained, the client sends an HTTP request
     2361   message (<xref target="http.message"/>) with a request-target derived from
     2362   the target URI.  There are four distinct formats for the request-target
     2363   (<xref target="request-target"/>), depending on both the method being
     2364   requested and whether the request is to a proxy.
    23082365</t>   
    23092366<t anchor="origin-form"><iref item="origin form (of request-target)"/>
Note: See TracChangeset for help on using the changeset viewer.