Ignore:
Timestamp:
Mar 11, 2012, 1:32:11 AM (8 years ago)
Author:
fielding@…
Message:

cleanup the phrasing of requirements in request-target and Host to
disambiguate the four cases and make the client responsible for compliance.

File:
1 edited

Legend:

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

    r1580 r1581  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 11, 2012";
     462       content: "Expires September 12, 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-10">
     512      <meta name="dct.issued" scheme="ISO8601" content="2012-03-11">
    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 11, 2012</td>
     544               <td class="left">Expires: September 12, 2012</td>
    545545               <td class="right">HP</td>
    546546            </tr>
     
    595595            <tr>
    596596               <td class="left"></td>
    597                <td class="right">March 10, 2012</td>
     597               <td class="right">March 11, 2012</td>
    598598            </tr>
    599599         </tbody>
     
    628628         in progress”.
    629629      </p>
    630       <p>This Internet-Draft will expire on September 11, 2012.</p>
     630      <p>This Internet-Draft will expire on September 12, 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>
     
    18771877         both the method being requested and whether the request is to a proxy.
    18781878      </p>
    1879       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.79"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
    1880                  / <a href="#uri" class="smpl">absolute-URI</a>
    1881                  / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
    1882                  / <a href="#uri" class="smpl">authority</a>
     1879      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span>  <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>
     1880                 / <a href="#absolute-form" class="smpl">absolute-form</a>
     1881                 / <a href="#authority-form" class="smpl">authority-form</a>
     1882                 / <a href="#asterisk-form" class="smpl">asterisk-form</a>
     1883
     1884  <a href="#origin-form" class="smpl">origin-form</a>    = <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     1885  <a href="#absolute-form" class="smpl">absolute-form</a>  = <a href="#uri" class="smpl">absolute-URI</a>
     1886  <a href="#authority-form" class="smpl">authority-form</a> = <a href="#uri" class="smpl">authority</a>
     1887  <a href="#asterisk-form" class="smpl">asterisk-form</a>  = "*"
    18831888</pre><div id="origin-form">
    1884          <p id="rfc.section.5.3.p.3"><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
    1885             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
    1886             as
     1889         <p id="rfc.section.5.3.p.3"><span id="rfc.iref.o.3"></span> The most common form of request-target is the origin-form. When making a request directly to an origin server, other than
     1890            a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send only the absolute path and query components of the target URI as the request-target. If the target URI's path component
     1891            is empty, then the client <em class="bcp14">MUST</em> send "/" as the path within the origin-form of request-target. A Host header field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;5.4</a>, containing the target URI's authority component (excluding any userinfo).
    18871892         </p>
    18881893      </div>
     1894      <p id="rfc.section.5.3.p.4">For example, a client wishing to retrieve a representation of the resource identified as</p>
    18891895      <div id="rfc.figure.u.46"></div><pre>http://www.example.org/where?q=now
    1890 </pre><p id="rfc.section.5.3.p.5">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the
     1896</pre><p id="rfc.section.5.3.p.6">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the
    18911897         lines:
    18921898      </p>
    18931899      <div id="rfc.figure.u.47"></div><pre class="text2">GET /where?q=now HTTP/1.1
    18941900Host: www.example.org
    1895 </pre><p id="rfc.section.5.3.p.7">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.
    1896          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.
    1897       </p>
    1898       <p id="rfc.section.5.3.p.8">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.
    1899       </p>
    1900       <div id="absolute-URI-form">
    1901          <p id="rfc.section.5.3.p.9"><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
    1902             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
    1903             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.
    1904             An example request-line would be:
     1901</pre><p id="rfc.section.5.3.p.8">followed by the remainder of the request message.</p>
     1902      <div id="absolute-form">
     1903         <p id="rfc.section.5.3.p.9"><span id="rfc.iref.a.2"></span> When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send the target URI in absolute-form as the request-target. The proxy is requested to either service that request from a valid
     1904            cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to
     1905            the origin server indicated by the request-target. In order to avoid request loops, a proxy that forwards requests to other
     1906            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.
    19051907         </p>
    19061908      </div>
     1909      <p id="rfc.section.5.3.p.10">An example absolute-form of request-line would be:</p>
    19071910      <div id="rfc.figure.u.48"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1908 </pre><p id="rfc.section.5.3.p.11">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.
    1909       </p>
    1910       <p id="rfc.section.5.3.p.12">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.
     1911</pre><p id="rfc.section.5.3.p.12">To allow for transition to the absolute-form for all requests in some future version of HTTP, HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies.
    19111912      </p>
    19121913      <div id="authority-form">
    1913          <p id="rfc.section.5.3.p.13"><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,
     1914         <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<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>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
    19141915         </p>
    19151916      </div>
    19161917      <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    1917 </pre><div id="asterix-form">
    1918          <p id="rfc.section.5.3.p.15"><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
    1919             process) rather than to a specific named resource at that server. For example,
     1918</pre><div id="asterisk-form">
     1919         <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1920            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    19201921         </p>
    19211922      </div>
    19221923      <div id="rfc.figure.u.50"></div><pre class="text2">OPTIONS * HTTP/1.1
    1923 </pre><p id="rfc.section.5.3.p.17">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
    1924          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.
     1924</pre><p id="rfc.section.5.3.p.17">If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query
     1925         component, then the last proxy on the request chain <em class="bcp14">MUST</em> send a request-target of "*" when it forwards the request to the indicated origin server.
    19251926      </p>
    19261927      <div id="rfc.figure.u.51"></div>
     
    19301931Host: www.example.org:8001
    19311932</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
    1932       <p id="rfc.section.5.3.p.20">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,
    1933          except as noted above to replace a null path-absolute with "/" or "*".
     1933      <p id="rfc.section.5.3.p.20">If a proxy receives a request-target with 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 when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
     1934      </p>
     1935      <p id="rfc.section.5.3.p.21">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,
     1936         except as noted above to replace an empty path with "/" or "*".
    19341937      </p>
    19351938      <div id="rfc.iref.h.10"></div>
    19361939      <div id="rfc.iref.h.11"></div>
    19371940      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    1938       <p id="rfc.section.5.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
    1939          server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the
    1940          Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line.
    1941       </p>
    1942       <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.80"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
    1943 </pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
    1944          the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
     1941      <p id="rfc.section.5.4.p.1">The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server
     1942         to distinguish among resources while servicing requests for multiple host names on a single IP address. Since the Host field-value
     1943         is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line.
     1944      </p>
     1945      <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
     1946</pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then the Host
     1947         field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    19451948      </p>
    19461949      <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    19471950      <div id="rfc.figure.u.54"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    19481951Host: www.example.org
    1949 </pre><p id="rfc.section.5.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
     1952</pre><p id="rfc.section.5.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information
    19501953         to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
    19511954      </p>
    1952       <p id="rfc.section.5.4.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
    1953          a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host.
     1955      <p id="rfc.section.5.4.p.7">When an HTTP/1.1 proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. If
     1956         the proxy forwards the request, it <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value.
    19541957      </p>
    19551958      <p id="rfc.section.5.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
    19561959         poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
    1957          relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared
    1958          cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.
     1960         relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache,
     1961         without first verifying that the intercepted connection is targeting a valid IP address for that host.
    19591962      </p>
    19601963      <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
    19611964         message that contains more than one Host header field or a Host header field with an invalid field-value.
    1962       </p>
    1963       <p id="rfc.section.5.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.5</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
    19641965      </p>
    19651966      <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>
     
    19861987      <div id="rfc.iref.e.1"></div>
    19871988      <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>
    1988       <p id="rfc.section.5.6.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection
     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
    19891990         context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
    19901991         by the effective request URI.
     
    20002001         </li>
    20012002         <li>the octet sequence "://",</li>
    2002          <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;5.4</a>), and
     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
    20032004         </li>
    20042005         <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li>
     
    20262027         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    20272028         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    2028          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.
     2029         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.
    20292030      </p>
    20302031      <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.
     
    20842085      <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.
    20852086      </p>
    2086       <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
     2087      <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.12"><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
    20872088         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.
    20882089      </p>
     
    21832184      <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>
    21842185      <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
    2185          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
     2186         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.13"><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
    21862187         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.
    21872188      </p>
     
    21962197      </p>
    21972198      <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>
    2198       <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
     2199      <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.14"><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
    21992200         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    22002201         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
     
    22032204      <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    22042205      <ul>
    2205          <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.
    2206          </li>
    2207          <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.
     2206         <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.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2207         </li>
     2208         <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.16"><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.
    22082209         </li>
    22092210      </ul>
     
    22492250         <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
    22502251            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    2251             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>).
     2252            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.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    22522253         </li>
    22532254      </ul>
     
    22952296               <tr>
    22962297                  <td class="left">Host</td>
    2297                   <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;5.4</a></td>
     2298                  <td class="left"><a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a></td>
    22982299               </tr>
    22992300               <tr>
     
    23312332      </p>
    23322333      <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p>
    2333       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
     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>
    23342335  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    23352336</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
     
    23672368         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    23682369      </p>
    2369       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.83"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
     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>
    23702371
    23712372  <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>]
     
    23892390      </p>
    23902391      <p id="rfc.section.8.2.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2391          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>).
     2392         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.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    23922393      </p>
    23932394      <p id="rfc.section.8.2.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
     
    24292430         of all senders along the request/response chain.
    24302431      </p>
    2431       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></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>
     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>
    24322433                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    24332434  <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>
     
    24982499                  <td class="left">http</td>
    24992500                  <td class="left">standard</td>
    2500                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a>
     2501                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;5.4</a>
    25012502                  </td>
    25022503               </tr>
     
    28092810         that most implementations will choose substantially higher limits.
    28102811      </p>
    2811       <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>).
     2812      <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.19"><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.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    28122813      </p>
    28132814      <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.
     
    30773078      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30783079      <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>
    3079       <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.
     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.
    30803081      </p>
    30813082      <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
     
    31753176
    31763177<a href="#uri" class="smpl">absolute-URI</a> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;
     3178<a href="#absolute-form" class="smpl">absolute-form</a> = absolute-URI
     3179<a href="#asterisk-form" class="smpl">asterisk-form</a> = "*"
    31773180<a href="#rule.parameter" class="smpl">attribute</a> = token
    31783181<a href="#uri" class="smpl">authority</a> = &lt;authority, defined in [RFC3986], Section 3.2&gt;
     3182<a href="#authority-form" class="smpl">authority-form</a> = authority
    31793183
    31803184<a href="#chunked.encoding" class="smpl">chunk</a> = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
     
    32073211<a href="#header.fields" class="smpl">obs-fold</a> = CRLF ( SP / HTAB )
    32083212<a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF
     3213<a href="#origin-form" class="smpl">origin-form</a> = path-absolute [ "?" query ]
    32093214
    32103215<a href="#uri" class="smpl">partial-URI</a> = relative-part [ "?" query ]
     
    32353240<a href="#uri" class="smpl">relative-part</a> = &lt;relative-part, defined in [RFC3986], Section 4.2&gt;
    32363241<a href="#request.line" class="smpl">request-line</a> = method SP request-target SP HTTP-version CRLF
    3237 <a href="#request-target" class="smpl">request-target</a> = "*" / absolute-URI / ( path-absolute [ "?" query ] )
    3238  / authority
     3242<a href="#request-target" class="smpl">request-target</a> = origin-form / absolute-form / authority-form /
     3243 asterisk-form
    32393244
    32403245<a href="#rule.token.separators" class="smpl">special</a> = "(" / ")" / "&lt;" / "&gt;" / "@" / "," / ";" / ":" / "\" /
     
    36693674         <ul class="ind">
    36703675            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    3671                   <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.3</a></li>
     3676                  <li>absolute-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.3</a></li>
    36723677                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
    36733678                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>9.3.2</b></a></li>
    3674                   <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.3</a></li>
    3675                   <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">5.3</a></li>
     3679                  <li>asterisk-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.3</a></li>
     3680                  <li>authority-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">5.3</a></li>
    36763681               </ul>
    36773682            </li>
     
    37133718                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    37143719                     <ul>
     3720                        <li><tt>absolute-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>5.3</b></a></li>
    37153721                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.7</b></a></li>
    37163722                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
     3723                        <li><tt>asterisk-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>5.3</b></a></li>
    37173724                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    37183725                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
     3726                        <li><tt>authority-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>5.3</b></a></li>
    37193727                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
    37203728                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>4.1</b></a></li>
     
    37263734                        <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>4.1</b></a></li>
    37273735                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.4</b></a></li>
    3728                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>8.1</b></a></li>
    3729                         <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>8.1</b></a></li>
     3736                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.1</b></a></li>
     3737                        <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.1</b></a></li>
    37303738                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>3.3.2</b></a></li>
    37313739                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
     
    37423750                        <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.2</b></a></li>
    37433751                        <li>HEXDIG&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>1.2</b></a></li>
    3744                         <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.4</b></a></li>
     3752                        <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>5.4</b></a></li>
    37453753                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    37463754                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>3</b></a></li>
     
    37563764                        <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.4</b></a></li>
    37573765                        <li>OCTET&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>1.2</b></a></li>
     3766                        <li><tt>origin-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.3</b></a></li>
    37583767                        <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2.1</b></a></li>
    37593768                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    37603769                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    3761                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.3</b></a></li>
    3762                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.3</b></a></li>
    3763                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.3</b></a></li>
     3770                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>8.3</b></a></li>
     3771                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>8.3</b></a></li>
     3772                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>8.3</b></a></li>
    37643773                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.4</b></a></li>
    37653774                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>4.1</b></a></li>
     
    37713780                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>4.4.1</b></a></li>
    37723781                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.2</b></a></li>
    3773                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.3</b></a></li>
    3774                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.3</b></a></li>
     3782                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>8.3</b></a></li>
     3783                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.3</b></a></li>
    37753784                        <li><tt>request-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>3.1.1</b></a></li>
    37763785                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.3</b></a></li>
     
    37933802                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>4</b></a></li>
    37943803                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    3795                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>8.2</b></a></li>
     3804                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.2</b></a></li>
    37963805                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    37973806                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    37983807                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>4</b></a></li>
    37993808                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3800                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.3</b></a></li>
     3809                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.3</b></a></li>
    38013810                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.4</b></a></li>
    38023811                     </ul>
     
    38113820                        <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>
    38123821                        <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>
    3813                         <li>Host&nbsp;&nbsp;<a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.1">5.6</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     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>
    38143823                        <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>
    38153824                        <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>
     
    38213830                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    38223831                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3823                   <li>Host header field&nbsp;&nbsp;<a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.1">5.6</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     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>
    38243833                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    38253834                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
     
    38553864            </li>
    38563865            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    3857                   <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">5.3</a></li>
    38583866                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
     3867                  <li>origin-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">5.3</a></li>
    38593868                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
    38603869               </ul>
     
    38623871            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38633872                  <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>
    3864                   <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.7</a>, <a href="#rfc.xref.Part2.11">6.1.2.2</a>, <a href="#rfc.xref.Part2.12">6.1.5</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a>, <a href="#rfc.xref.Part2.17">8.2</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     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>
    38653874                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1</a></li>
    38663875                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    38673876                        <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</a></li>
    3868                         <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>
     3877                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.1.2.2</a>, <a href="#rfc.xref.Part2.13">6.1.5</a></li>
     3878                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">5.3</a></li>
    38693879                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.3</a></li>
    3870                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">5.7</a>, <a href="#rfc.xref.Part2.16">6.2.3</a></li>
    3871                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.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>
     3881                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.2.3</a></li>
    38723882                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    3873                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">8.2</a></li>
    3874                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">10.6</a></li>
    3875                         <li><em>Section 7.4.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.18">10.6</a></li>
     3883                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">8.2</a></li>
     3884                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">10.6</a></li>
     3885                        <li><em>Section 7.4.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.19">10.6</a></li>
    38763886                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
    3877                         <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>
     3887                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a></li>
    38783888                     </ul>
    38793889                  </li>
     
    39293939                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li>
    39303940                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
    3931                   <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.3</a>, <a href="#rfc.xref.RFC3986.20">5.6</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
    3932                         <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>
     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>
     3942                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a></li>
    39333943                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
    39343944                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.7.1</a></li>
     
    39403950                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li>
    39413951                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li>
    3942                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.6</a></li>
     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>
    39433953                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li>
    39443954                     </ul>
Note: See TracChangeset for help on using the changeset viewer.