Ignore:
Timestamp:
11/03/12 09:32:11 (11 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.

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/httpbis.abnf

    r1557 r1581  
    6262Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] )
    6363absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
     64absolute-form = absolute-URI
    6465accept-ext = OWS ";" OWS token [ "=" word ]
    6566accept-params = OWS ";" OWS "q=" qvalue *accept-ext
    6667acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS range-unit ] ) ) / "none"
    6768asctime-date = day-name SP date3 SP time-of-day SP year
     69asterisk-form = "*"
    6870attribute = token
    6971auth-param = token BWS "=" BWS ( token / quoted-string )
    7072auth-scheme = token
    7173authority = <authority, defined in [RFC3986], Section 3.2>
     74authority-form = authority
    7275b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
    7376byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( instance-length / "*" )
    … …  
    164167obs-text = %x80-FF
    165168opaque-tag = DQUOTE *etagc DQUOTE
     169origin-form = path-absolute [ "?" query ]
    166170other-content-range-spec = other-range-unit SP other-range-resp-spec
    167171other-range-resp-spec = *CHAR
    … …  
    199203relative-part = <relative-part, defined in [RFC3986], Section 4.2>
    200204request-line = method SP request-target SP HTTP-version CRLF
    201 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) / authority
     205request-target = origin-form / absolute-form / authority-form / asterisk-form
    202206rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
    203207rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT

  • 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>

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

    r1579 r1581  
    3333  <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3434  <!ENTITY method                 "<xref target='Part2' x:rel='#method' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     35  <!ENTITY OPTIONS                "<xref target='Part2' x:rel='#OPTIONS' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3536  <!ENTITY status-code-reasonphr  "<xref target='Part2' x:rel='#status.code.and.reason.phrase' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3637  <!ENTITY status-codes           "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    23602361   the method being requested and whether the request is to a proxy.
    23612362</t>   
    2362 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/>
    2363   <x:ref>request-target</x:ref> = "*"
    2364                  / <x:ref>absolute-URI</x:ref>
    2365                  / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] )
    2366                  / <x:ref>authority</x:ref>
     2363<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/><iref primary="true" item="Grammar" subitem="origin-form"/><iref primary="true" item="Grammar" subitem="absolute-form"/><iref primary="true" item="Grammar" subitem="authority-form"/><iref primary="true" item="Grammar" subitem="asterisk-form"/>
     2364  <x:ref>request-target</x:ref> = <x:ref>origin-form</x:ref>
     2365                 / <x:ref>absolute-form</x:ref>
     2366                 / <x:ref>authority-form</x:ref>
     2367                 / <x:ref>asterisk-form</x:ref>
     2368
     2369  <x:ref>origin-form</x:ref>    = <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]
     2370  <x:ref>absolute-form</x:ref>  = <x:ref>absolute-URI</x:ref>
     2371  <x:ref>authority-form</x:ref> = <x:ref>authority</x:ref>
     2372  <x:ref>asterisk-form</x:ref>  = "*"
    23672373</artwork></figure>
    2368 <t anchor="origin-form"><iref item="origin form (of request-target)"/>
    2369    The most common form of request-target is that used when making
    2370    a request to an origin server ("origin form") to access a resource
    2371    identified by an "http" (<xref target="http.uri"/>) or
    2372    "https" (<xref target="https.uri"/>) URI.
    2373    In this case, the absolute path and query components of the URI
    2374    &MUST; be transmitted as the request-target and the authority component
    2375    (excluding any userinfo) &MUST; be transmitted in a Host header field.
     2374<t anchor="origin-form"><iref item="origin-form (of request-target)"/>
     2375   The most common form of request-target is the origin-form.
     2376   When making a request directly to an origin server, other than a CONNECT
     2377   or server-wide OPTIONS request (as detailed below),
     2378   a client &MUST; send only the absolute path and query components of
     2379   the target URI as the request-target.
     2380   If the target URI's path component is empty, then the client &MUST; send
     2381   "/" as the path within the origin-form of request-target.
     2382   A Host header field is also sent, as defined in
     2383   <xref target="header.host"/>, containing the target URI's
     2384   authority component (excluding any userinfo).
     2385</t>
     2386<t>
    23762387   For example, a client wishing to retrieve a representation of the resource
    23772388   identified as
    … …  
    23892400</artwork></figure>
    23902401<t>
    2391    followed by the remainder of the request. Note that the origin form
    2392    of request-target always starts with an absolute path. If the target
    2393    resource's URI path is empty, then an absolute path of "/" &MUST; be
    2394    provided in the request-target.
    2395 </t>
    2396 <t>
    2397    If the request-target is percent-encoded
    2398    (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server
    2399    &MUST; decode the request-target in order to
    2400    properly interpret the request. Servers &SHOULD; respond to invalid
    2401    request-targets with an appropriate status code.
    2402 </t>
    2403 <t anchor="absolute-URI-form"><iref item="absolute-URI form (of request-target)"/>
    2404    The "absolute-URI" form of request-target is &REQUIRED; when the request
    2405    is being made to a proxy.  The proxy is requested to either forward the
    2406    request or service it from a valid cache, and then return the response.
    2407    Note that the proxy &MAY; forward the request on to another proxy or
    2408    directly to the server specified by the absolute-URI.
     2402   followed by the remainder of the request message.
     2403</t>
     2404<t anchor="absolute-form"><iref item="absolute-form (of request-target)"/>
     2405   When making a request to a proxy, other than a CONNECT or server-wide
     2406   OPTIONS request (as detailed below), a client &MUST; send the target URI
     2407   in absolute-form as the request-target.
     2408   The proxy is requested to either service that request from a valid cache,
     2409   if possible, or make the same request on the client's behalf to either
     2410   the next inbound proxy server or directly to the origin server indicated
     2411   by the request-target.
    24092412   In order to avoid request loops, a proxy that forwards requests to other
    24102413   proxies &MUST; be able to recognize and exclude all of its own server
    24112414   names, including any aliases, local variations, or literal IP addresses.
    2412    An example request-line would be:
     2415</t>
     2416<t>
     2417   An example absolute-form of request-line would be:
    24132418</t>
    24142419<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    24162421</artwork></figure>
    24172422<t>
    2418    To allow for transition to absolute-URIs in all requests in future
    2419    versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI
    2420    form in requests, even though HTTP/1.1 clients will only generate
    2421    them in requests to proxies.
    2422 </t>
    2423 <t>
    2424    If a proxy receives a host name that is not a fully qualified domain
    2425    name, it &MAY; add its domain to the host name it received. If a proxy
    2426    receives a fully qualified domain name, the proxy &MUST-NOT; change
    2427    the host name.
    2428 </t>
    2429 <t anchor="authority-form"><iref item="authority form (of request-target)"/>
    2430    The "authority form" of request-target, which &MUST-NOT; be used
    2431    with any request method other than CONNECT, is used to establish a
    2432    tunnel through one or more proxies (&CONNECT;).  For example,
     2423   To allow for transition to the absolute-form for all requests in some
     2424   future version of HTTP, HTTP/1.1 servers &MUST; accept the absolute-form
     2425   in requests, even though HTTP/1.1 clients will only send them in requests
     2426   to proxies.
     2427</t>
     2428<t anchor="authority-form"><iref item="authority-form (of request-target)"/>
     2429   The authority-form of request-target is only used for CONNECT requests
     2430   (&CONNECT;).  When making a CONNECT request to establish a tunnel through
     2431   one or more proxies, a client &MUST; send only the target URI's
     2432   authority component (excluding any userinfo) as the request-target.
     2433   For example,
    24332434</t>
    24342435<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    24352436CONNECT www.example.com:80 HTTP/1.1
    24362437</artwork></figure>
    2437 <t anchor="asterix-form"><iref item="asterisk form (of request-target)"/>
    2438    The asterisk ("*") form of request-target, which &MUST-NOT; be used
    2439    with any request method other than OPTIONS, means that the request
    2440    applies to the server as a whole (the listening process) rather than
    2441    to a specific named resource at that server.  For example,
     2438<t anchor="asterisk-form"><iref item="asterisk-form (of request-target)"/>
     2439   The asterisk-form of request-target is only used for a server-wide
     2440   OPTIONS request (&OPTIONS;).  When a client wishes to request OPTIONS
     2441   for the server as a whole, as opposed to a specific named resource of
     2442   that server, the client &MUST; send only "*" (%x2A) as the request-target.
     2443   For example,
    24422444</t>
    24432445<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    24452447</artwork></figure>
    24462448<t>
    2447    If a proxy receives an OPTIONS request with an absolute-URI form of
     2449   If a proxy receives an OPTIONS request with an absolute-form of
    24482450   request-target in which the URI has an empty path and no query component,
    2449    then the last proxy on the request chain &MUST; use a request-target
     2451   then the last proxy on the request chain &MUST; send a request-target
    24502452   of "*" when it forwards the request to the indicated origin server.
    24512453</t>
    … …  
    24662468</figure>
    24672469<t>
     2470   If a proxy receives a request-target with a host name that is not a
     2471   fully qualified domain name, it &MAY; add its domain to the host name
     2472   it received when forwarding the request.  A proxy &MUST-NOT; change the
     2473   host name if it is a fully qualified domain name.
     2474</t>
     2475<t>
    24682476   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
    24692477   parts of the received request-target when forwarding it to the next inbound
    2470    server, except as noted above to replace a null path-absolute with "/" or
    2471    "*".
     2478   server, except as noted above to replace an empty path with "/" or "*".
    24722479</t>
    24732480</section>
    … …  
    24792486<t>
    24802487   The "Host" header field in a request provides the host and port
    2481    information from the target resource's URI, enabling the origin
    2482    server to distinguish between resources while servicing requests
     2488   information from the target URI, enabling the origin
     2489   server to distinguish among resources while servicing requests
    24832490   for multiple host names on a single IP address.  Since the Host
    24842491   field-value is critical information for handling a request, it
    … …  
    24902497<t>
    24912498   A client &MUST; send a Host header field in all HTTP/1.1 request
    2492    messages.  If the target resource's URI includes an authority
    2493    component, then the Host field-value &MUST; be identical to that
    2494    authority component after excluding any userinfo (<xref target="http.uri"/>).
    2495    If the authority component is missing or undefined for the target
    2496    resource's URI, then the Host header field &MUST; be sent with an
    2497    empty field-value.
     2499   messages.  If the target URI includes an authority component, then
     2500   the Host field-value &MUST; be identical to that authority component
     2501   after excluding any userinfo (<xref target="http.uri"/>).
     2502   If the authority component is missing or undefined for the target URI,
     2503   then the Host header field &MUST; be sent with an empty field-value.
    24982504</t>
    24992505<t>
    … …  
    25072513<t>
    25082514   The Host header field &MUST; be sent in an HTTP/1.1 request even
    2509    if the request-target is in the form of an absolute-URI, since this
     2515   if the request-target is in the absolute-form, since this
    25102516   allows the Host information to be forwarded through ancient HTTP/1.0
    25112517   proxies that might not have implemented Host.
    25122518</t>
    25132519<t>
    2514    When an HTTP/1.1 proxy receives a request with a request-target in
    2515    the form of an absolute-URI, the proxy &MUST; ignore the received
     2520   When an HTTP/1.1 proxy receives a request with an absolute-form of
     2521   request-target, the proxy &MUST; ignore the received
    25162522   Host header field (if any) and instead replace it with the host
    2517    information of the request-target.  When a proxy forwards a request,
    2518    it &MUST; generate the Host header field based on the received
    2519    absolute-URI rather than the received Host.
     2523   information of the request-target.  If the proxy forwards the request,
     2524   it &MUST; generate a new Host field-value based on the received
     2525   request-target rather than forward the received Host field-value.
    25202526</t>
    25212527<t>
    … …  
    25242530   a shared cache or redirect a request to an unintended server.
    25252531   An interception proxy is particularly vulnerable if it relies on
    2526    the Host header field value for redirecting requests to internal
     2532   the Host field-value for redirecting requests to internal
    25272533   servers, or for use as a cache key in a shared cache, without
    25282534   first verifying that the intercepted connection is targeting a
    … …  
    25342540   to any request message that contains more than one Host header field
    25352541   or a Host header field with an invalid field-value.
    2536 </t>
    2537 <t>
    2538    See Sections <xref target="the.resource.identified.by.a.request" format="counter"/>
    2539    and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>
    2540    for other requirements relating to Host.
    25412542</t>
    25422543</section>
    … …  
    51445145
    51455146<x:ref>absolute-URI</x:ref> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;
     5147<x:ref>absolute-form</x:ref> = absolute-URI
     5148<x:ref>asterisk-form</x:ref> = "*"
    51465149<x:ref>attribute</x:ref> = token
    51475150<x:ref>authority</x:ref> = &lt;authority, defined in [RFC3986], Section 3.2&gt;
     5151<x:ref>authority-form</x:ref> = authority
    51485152
    51495153<x:ref>chunk</x:ref> = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
    … …  
    51765180<x:ref>obs-fold</x:ref> = CRLF ( SP / HTAB )
    51775181<x:ref>obs-text</x:ref> = %x80-FF
     5182<x:ref>origin-form</x:ref> = path-absolute [ "?" query ]
    51785183
    51795184<x:ref>partial-URI</x:ref> = relative-part [ "?" query ]
    … …  
    52045209<x:ref>relative-part</x:ref> = &lt;relative-part, defined in [RFC3986], Section 4.2&gt;
    52055210<x:ref>request-line</x:ref> = method SP request-target SP HTTP-version CRLF
    5206 <x:ref>request-target</x:ref> = "*" / absolute-URI / ( path-absolute [ "?" query ] )
    5207  / authority
     5211<x:ref>request-target</x:ref> = origin-form / absolute-form / authority-form /
     5212 asterisk-form
    52085213
    52095214<x:ref>special</x:ref> = "(" / ")" / "&lt;" / "&gt;" / "@" / "," / ";" / ":" / "\" /
Note: See TracChangeset for help on using the changeset viewer.