Changeset 387


Ignore:
Timestamp:
Nov 14, 2008, 1:21:24 PM (11 years ago)
Author:
fielding@…
Message:

clean up the URI section; s/Request-URI/request-target/g

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

Legend:

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

    r373 r387  
    477477         <tr>
    478478            <td class="header left"></td>
    479             <td class="header right">November 13, 2008</td>
     479            <td class="header right">November 14, 2008</td>
    480480         </tr>
    481481      </table>
     
    567567               <li class="tocline1">5.1&nbsp;&nbsp;&nbsp;<a href="#request-line">Request-Line</a><ul class="toc">
    568568                     <li class="tocline1">5.1.1&nbsp;&nbsp;&nbsp;<a href="#method">Method</a></li>
    569                      <li class="tocline1">5.1.2&nbsp;&nbsp;&nbsp;<a href="#request-uri">Request-URI</a></li>
     569                     <li class="tocline1">5.1.2&nbsp;&nbsp;&nbsp;<a href="#request-target">request-target</a></li>
    570570                  </ul>
    571571               </li>
     
    810810  <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>&gt;
    811811</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP architecture</a></h1>
    812       <p id="rfc.section.2.p.1">Nevertheless, HTTP was created with a specific architecture in mind, the World Wide Web, and has evolved over time to support
    813          the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology used to define
    814          HTTP. This section describes the larger architecture surrounding expected usage of HTTP that is used by this specification
     812      <p id="rfc.section.2.p.1">HTTP was created with a specific architecture in mind, the World Wide Web, and has evolved over time to support the scalability
     813         needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology and syntax productions used
    815814         to define HTTP.
    816815      </p>
    817816      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    818       <p id="rfc.section.2.1.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used in HTTP to indicate the target of a request and to identify additional resources related to that resource, the request,
    819          or the response. Each protocol element in HTTP that allows a URI reference will indicate in its ABNF whether the element allows
    820          only a URI in absolute form, any relative reference, or some limited subset of the URI-reference grammar. Unless otherwise
    821          indicated, relative URI references are to be parsed relative to the URI corresponding to the request target (the base URI).
    822       </p>
    823       <p id="rfc.section.2.1.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", "host", "path-abempty",
    824          "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>:
    825       </p>
    826       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#uri" class="smpl">absolute-URI</a>   = &lt;absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.4"><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>&gt;
    827   <a href="#uri" class="smpl">authority</a>     = &lt;authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>&gt;
    828   <a href="#uri" class="smpl">fragment</a>      = &lt;fragment, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>&gt;
    829   <a href="#uri" class="smpl">path-abempty</a>  = &lt;path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>&gt;
    830   <a href="#uri" class="smpl">path-absolute</a> = &lt;path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>&gt;
    831   <a href="#uri" class="smpl">port</a>          = &lt;port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>&gt;
    832   <a href="#uri" class="smpl">query</a>         = &lt;query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>&gt;
    833   <a href="#uri" class="smpl">uri-host</a>      = &lt;host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>&gt;
    834 </pre><p id="rfc.section.2.1.p.4">HTTP does not place an a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    835       </p>
    836       <p id="rfc.section.2.1.p.5"> </p>
    837       <dl class="empty">
    838          <dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations
    839             might not properly support these lengths.
    840          </dd>
    841       </dl>
     817      <p id="rfc.section.2.1.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, redirect responses,
     818         and define relationships. HTTP does not limit what a resource may be; it merely defines an interface that can be used to interact
     819         with a resource via HTTP. More information on the scope of URIs and resources can be found in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
     820      </p>
     821      <p id="rfc.section.2.1.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "fragment", "port", "host",
     822         "path-abempty", "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI without a fragment.
     823      </p>
     824      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#uri" class="smpl">URI</a>           = &lt;URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3">Section 3</a>&gt;
     825  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
     826  <a href="#uri" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><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>&gt;
     827  <a href="#uri" class="smpl">relative-part</a> = &lt;relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>&gt;
     828  <a href="#uri" class="smpl">authority</a>     = &lt;authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>&gt;
     829  <a href="#uri" class="smpl">fragment</a>      = &lt;fragment, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>&gt;
     830  <a href="#uri" class="smpl">path-abempty</a>  = &lt;path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>&gt;
     831  <a href="#uri" class="smpl">path-absolute</a> = &lt;path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>&gt;
     832  <a href="#uri" class="smpl">port</a>          = &lt;port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>&gt;
     833  <a href="#uri" class="smpl">query</a>         = &lt;query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>&gt;
     834  <a href="#uri" class="smpl">uri-host</a>      = &lt;host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>&gt;
     835 
     836  <a href="#uri" class="smpl">partial-URI</a>   = relative-part [ "?" query ]
     837</pre><p id="rfc.section.2.1.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
     838         only a URI in absolute form (absolute-URI), any relative reference (relative-ref), or some other subset of the URI-reference
     839         grammar. Unless otherwise indicated, URI references are parsed relative to the request target (the default base URI for both
     840         the request and its corresponding response).
     841      </p>
    842842      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
    843843      <div id="rfc.iref.h.1"></div>
     
    848848      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    849849</pre><p id="rfc.section.2.1.1.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server
    850          listening for TCP connections on that port of that host, and the Request-URI for the resource is path-absolute (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). If a proxy receives a host name which 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.
     850         listening for TCP connections on that port of that host, and the request-target for the resource is path-absolute (<a href="#request-target" title="request-target">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a request-target for a resource (<a href="#request-target" title="request-target">Section&nbsp;5.1.2</a>). If a proxy receives a host name which 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.
    851851      </p>
    852852      <dl class="empty">
     
    865865         <li>An empty path-absolute is equivalent to an path-absolute of "/".</li>
    866866      </ul>
    867       <p id="rfc.section.2.1.2.p.2">Characters other than those in the "reserved" set (see <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#core.rules" class="smpl">HEXDIG</a>  <a href="#core.rules" class="smpl">HEXDIG</a>" encoding.
     867      <p id="rfc.section.2.1.2.p.2">Characters other than those in the "reserved" set (see <a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#core.rules" class="smpl">HEXDIG</a>  <a href="#core.rules" class="smpl">HEXDIG</a>" encoding.
    868868      </p>
    869869      <p id="rfc.section.2.1.2.p.3">For example, the following three URIs are equivalent:</p>
     
    11641164      </p>
    11651165      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="message.headers" href="#message.headers">Message Headers</a></h2>
    1166       <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
     1166      <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
    11671167         field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding
    11681168         each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated,
     
    12081208      <p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    12091209      <p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    1210          in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
     1210         in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
    12111211         and a method that does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented
    12121212         the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response.
     
    12881288      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.72"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;5.1</a>
    12891289                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1290                    / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>
     1290                   / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>
    12911291                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>
    12921292                  <a href="#core.rules" class="smpl">CRLF</a>
    12931293                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
    12941294</pre><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="request-line" href="#request-line">Request-Line</a></h2>
    1295       <p id="rfc.section.5.1.p.1">The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The
    1296          elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
    1297       </p>
    1298       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-uri" class="smpl">Request-URI</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
     1295      <p id="rfc.section.5.1.p.1">The Request-Line begins with a method token, followed by the request-target and the protocol version, and ending with CRLF.
     1296         The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
     1297      </p>
     1298      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
    12991299</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h3>
    1300       <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>
     1300      <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p>
    13011301      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1302 </pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="request-uri" href="#request-uri">Request-URI</a></h3>
    1303       <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.1</a>) and identifies the resource upon which to apply the request.
    1304       </p>
    1305       <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.76"></span>  <a href="#request-uri" class="smpl">Request-URI</a>    = "*"
     1302</pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
     1303      <p id="rfc.section.5.1.2.p.1">The request-target is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.1</a>) and identifies the resource upon which to apply the request.
     1304      </p>
     1305      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.76"></span>  <a href="#request-target" class="smpl">request-target</a>    = "*"
    13061306                 / <a href="#uri" class="smpl">absolute-URI</a>
    13071307                 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
    13081308                 / <a href="#uri" class="smpl">authority</a>
    1309 </pre><p id="rfc.section.5.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does
     1309</pre><p id="rfc.section.5.1.2.p.3">The four options for request-target are dependent on the nature of the request. The asterisk "*" means that the request does
    13101310         not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
    13111311         apply to a resource. One example would be
     
    13201320</pre><p id="rfc.section.5.1.2.p.7">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.
    13211321      </p>
    1322       <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    1323       </p>
    1324       <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute
    1325          path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>, path-absolute) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
     1322      <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1323      </p>
     1324      <p id="rfc.section.5.1.2.p.9">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the
     1325         absolute path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>, path-absolute) as the request-target, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
    13261326         server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
    13271327      </p>
     
    13311331         URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
    13321332      </p>
    1333       <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>. If the Request-URI is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a>  <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</a>), the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
    1334       </p>
    1335       <p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received Request-URI when forwarding it to the next inbound server, except as noted
     1333      <p id="rfc.section.5.1.2.p.12">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>. If the request-target is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a>  <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</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.
     1334      </p>
     1335      <p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted
    13361336         above to replace a null path-absolute with "/".
    13371337      </p>
     
    13401340         <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
    13411341            a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
    1342             known to rewrite the Request-URI.
     1342            known to rewrite the request-target.
    13431343         </dd>
    13441344      </dl>
     1345      <p id="rfc.section.5.1.2.p.15">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI too long) status if the received request-target
     1346         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1347      </p>
     1348      <p id="rfc.section.5.1.2.p.16">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.
     1349      </p>
    13451350      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
    1346       <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p>
     1351      <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header
     1352         field.
     1353      </p>
    13471354      <p id="rfc.section.5.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix&nbsp;C.1.1</a> for other requirements on Host support in HTTP/1.1.)
    13481355      </p>
     
    13511358      </p>
    13521359      <ol>
    1353          <li>If Request-URI is an absolute-URI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
    1354          </li>
    1355          <li>If the Request-URI is not an absolute-URI, and the request includes a Host header field, the host is determined by the Host
    1356             header field value.
     1360         <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
     1361         </li>
     1362         <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the
     1363            Host header field value.
    13571364         </li>
    13581365         <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.
     
    20492056         If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft
    20502057         Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    2051          such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to
    2052          be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access control
    2053          files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor
     2058         such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the request-target if it would otherwise allow access to a resource outside those intended
     2059         to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access
     2060         control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor
    20542061         bugs in such HTTP server implementations have turned into security risks.
    20552062      </p>
     
    23882395      <p id="rfc.section.C.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    23892396      <h3 id="rfc.section.C.1.1"><a href="#rfc.section.C.1.1">C.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">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3>
    2390       <p id="rfc.section.C.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>) are among the most important changes defined by this specification.
     2397      <p id="rfc.section.C.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;5.1.2</a>) are among the most important changes defined by this specification.
    23912398      </p>
    23922399      <p id="rfc.section.C.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
     
    24522459      <p id="rfc.section.C.4.p.4">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.3.1</a>)
    24532460      </p>
    2454       <p id="rfc.section.C.4.p.5">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>)
     2461      <p id="rfc.section.C.4.p.5">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-target" title="request-target">Section&nbsp;5.1.2</a>)
    24552462      </p>
    24562463      <p id="rfc.section.C.4.p.6">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a>)
     
    28532860                        <li class="indline1"><tt>Request</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.72"><b>5</b></a></li>
    28542861                        <li class="indline1"><tt>Request-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.73"><b>5.1</b></a></li>
    2855                         <li class="indline1"><tt>Request-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.76"><b>5.1.2</b></a></li>
     2862                        <li class="indline1"><tt>request-target</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.76"><b>5.1.2</b></a></li>
    28562863                        <li class="indline1"><tt>Response</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.77"><b>6</b></a></li>
    28572864                        <li class="indline1"><tt>rfc1123-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>3.2.1</b></a></li>
     
    29362943            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    29372944                  <li class="indline1"><em>Pad1995</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li>
    2938                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">2.1</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">4.3</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">
    2939                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">4.3</a></li>
    2940                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a></li>
    2941                         <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li>
     2945                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.3</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a>, <a class="iref" href="#rfc.xref.Part2.7">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">
     2946                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">4.3</a></li>
     2947                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a></li>
     2948                        <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li>
    29422949                        <li class="indline1"><em>Section 8.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a></li>
    2943                         <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">5.1.2</a></li>
     2950                        <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.7">5.1.2</a></li>
    29442951                        <li class="indline1"><em>Section 9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.10">6.1.1</a></li>
    29452952                        <li class="indline1"><em>Section 9.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
    29462953                        <li class="indline1"><em>Section 9.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.16">7.2.3</a></li>
    2947                         <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">2.1</a></li>
     2954                        <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">5.1.2</a></li>
    29482955                        <li class="indline1"><em>Section 10.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a></li>
    29492956                     </ul>
     
    29963003                  <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">9.1</a>, <a class="iref" href="#RFC3864"><b>12.2</b></a></li>
    29973004                  <li class="indline1"><em>RFC3977</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3977.1">1</a>, <a class="iref" href="#RFC3977"><b>12.2</b></a></li>
    2998                   <li class="indline1"><em>RFC3986</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.13">5.1.2</a>, <a class="iref" href="#RFC3986"><b>12.1</b></a><ul class="ind">
    2999                         <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.12">2.1.2</a></li>
    3000                         <li class="indline1"><em>Section 2.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.13">5.1.2</a></li>
    3001                         <li class="indline1"><em>Section 3.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.9">2.1</a></li>
    3002                         <li class="indline1"><em>Section 3.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.11">2.1</a></li>
    3003                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.5">2.1</a></li>
    3004                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.7">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.1</a></li>
    3005                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.10">2.1</a></li>
    3006                         <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.6">2.1</a></li>
    3007                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.4">2.1</a></li>
     3005                  <li class="indline1"><em>RFC3986</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.13">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.14">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.15">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.16">2.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.17">5.1.2</a>, <a class="iref" href="#RFC3986"><b>12.1</b></a><ul class="ind">
     3006                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.16">2.1.2</a></li>
     3007                        <li class="indline1"><em>Section 2.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.17">5.1.2</a></li>
     3008                        <li class="indline1"><em>Section 3.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.13">2.1</a></li>
     3009                        <li class="indline1"><em>Section 3.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.15">2.1</a></li>
     3010                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.9">2.1</a></li>
     3011                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.11">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.1</a></li>
     3012                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.14">2.1</a></li>
     3013                        <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.10">2.1</a></li>
     3014                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.5">2.1</a></li>
     3015                        <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.6">2.1</a></li>
     3016                        <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.8">2.1</a></li>
     3017                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.7">2.1</a></li>
    30083018                     </ul>
    30093019                  </li>
  • draft-ietf-httpbis/latest-roy/p1-messaging.xml

    r373 r387  
    517517<section title="HTTP architecture" anchor="architecture">
    518518<t>
    519    Nevertheless, HTTP was created with a specific architecture in mind, the
    520    World Wide Web, and has evolved over time to support the scalability needs
    521    of a worldwide hypertext system. Much of that architecture is reflected in
    522    the terminology used to define HTTP. This section describes the larger
    523    architecture surrounding expected usage of HTTP that is used by this
    524    specification to define HTTP.
     519   HTTP was created with a specific architecture in mind, the World Wide Web,
     520   and has evolved over time to support the scalability needs of a worldwide
     521   hypertext system. Much of that architecture is reflected in the terminology
     522   and syntax productions used to define HTTP.
    525523</t>
    526524
    527525<section title="Uniform Resource Identifiers" anchor="uri">
    528526<t>
    529    Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP
    530    to indicate the target of a request and to identify additional resources related
    531    to that resource, the request, or the response. Each protocol element in HTTP
    532    that allows a URI reference will indicate in its ABNF whether the element allows
    533    only a URI in absolute form, any relative reference, or some limited subset of
    534    the URI-reference grammar. Unless otherwise indicated, relative URI references
    535    are to be parsed relative to the URI corresponding to the request target
    536    (the base URI).
    537 </t>
     527   Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used
     528   throughout HTTP as the means for identifying resources. URI references
     529   are used to target requests, redirect responses, and define relationships.
     530   HTTP does not limit what a resource may be; it merely defines an interface
     531   that can be used to interact with a resource via HTTP. More information on
     532   the scope of URIs and resources can be found in <xref target="RFC3986"/>.
     533</t>
     534  <x:anchor-alias value="URI"/>
    538535  <x:anchor-alias value="URI-reference"/>
    539536  <x:anchor-alias value="absolute-URI"/>
     537  <x:anchor-alias value="relative-part"/>
    540538  <x:anchor-alias value="authority"/>
    541539  <x:anchor-alias value="fragment"/>
     
    545543  <x:anchor-alias value="query"/>
    546544  <x:anchor-alias value="uri-host"/>
    547 <t>
    548    This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port",
    549    "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>:
     545  <x:anchor-alias value="partial-URI"/>
     546<t>
     547   This specification adopts the definitions of "URI-reference",
     548   "absolute-URI", "relative-part", "fragment", "port", "host",
     549   "path-abempty", "path-absolute", "query", and "authority" from
     550   <xref target="RFC3986"/>. In addition, we define a partial-URI rule for
     551   protocol elements that allow a relative URI without a fragment.
    550552</t>
    551553<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/>
    552   <x:ref>absolute-URI</x:ref>   = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
     554  <x:ref>URI</x:ref>           = &lt;URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/>>
     555  <x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/>>
     556  <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
     557  <x:ref>relative-part</x:ref> = &lt;relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>>
    553558  <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>
    554559  <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>
     
    558563  <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>
    559564  <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>>
    560 </artwork></figure>
    561 <t>
    562    HTTP does not place an a priori limit on the length of
    563    a URI. Servers &MUST; be able to handle the URI of any resource they
    564    serve, and &SHOULD; be able to handle URIs of unbounded length if they
    565    provide GET-based forms that could generate such URIs. A server
    566    &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer
    567    than the server can handle (see &status-414;).
    568 </t>
    569 <t>
    570   <list>
    571     <t>
    572       <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths
    573       above 255 bytes, because some older client or proxy
    574       implementations might not properly support these lengths.
    575     </t>
    576   </list>
     565 
     566  <x:ref>partial-URI</x:ref>   = relative-part [ "?" query ]
     567</artwork></figure>
     568<t>
     569   Each protocol element in HTTP that allows a URI reference will indicate in
     570   its ABNF production whether the element allows only a URI in absolute form
     571   (absolute-URI), any relative reference (relative-ref), or some other subset
     572   of the URI-reference grammar. Unless otherwise indicated, URI references
     573   are parsed relative to the request target (the default base URI for both
     574   the request and its corresponding response).
    577575</t>
    578576
     
    592590   If the port is empty or not given, port 80 is assumed. The semantics
    593591   are that the identified resource is located at the server listening
    594    for TCP connections on that port of that host, and the Request-URI
    595    for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses
     592   for TCP connections on that port of that host, and the request-target
     593   for the resource is path-absolute (<xref target="request-target"/>). The use of IP addresses
    596594   in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
    597595   the path-absolute is not present in the URL, it &MUST; be given as "/" when
    598    used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
     596   used as a request-target for a resource (<xref target="request-target"/>). If a proxy
    599597   receives a host name which is not a fully qualified domain name, it
    600598   &MAY; add its domain to the host name it received. If a proxy receives
     
    14551453<t>
    14561454   The Request-Line begins with a method token, followed by the
    1457    Request-URI and the protocol version, and ending with CRLF. The
     1455   request-target and the protocol version, and ending with CRLF. The
    14581456   elements are separated by SP characters. No CR or LF is allowed
    14591457   except in the final CRLF sequence.
    14601458</t>
    14611459<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-Line"/>
    1462   <x:ref>Request-Line</x:ref>   = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref>Request-URI</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref>
     1460  <x:ref>Request-Line</x:ref>   = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref>
    14631461</artwork></figure>
    14641462
     
    14671465<t>
    14681466   The Method  token indicates the method to be performed on the
    1469    resource identified by the Request-URI. The method is case-sensitive.
     1467   resource identified by the request-target. The method is case-sensitive.
    14701468</t>
    14711469<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/>
     
    14741472</section>
    14751473
    1476 <section title="Request-URI" anchor="request-uri">
    1477   <x:anchor-alias value="Request-URI"/>
    1478 <t>
    1479    The Request-URI is a Uniform Resource Identifier (<xref target="uri"/>) and
     1474<section title="request-target" anchor="request-target">
     1475  <x:anchor-alias value="request-target"/>
     1476<t>
     1477   The request-target is a Uniform Resource Identifier (<xref target="uri"/>) and
    14801478   identifies the resource upon which to apply the request.
    14811479</t>
    1482 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/>
    1483   <x:ref>Request-URI</x:ref>    = "*"
     1480<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/>
     1481  <x:ref>request-target</x:ref>    = "*"
    14841482                 / <x:ref>absolute-URI</x:ref>
    14851483                 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] )
     
    14871485</artwork></figure>
    14881486<t>
    1489    The four options for Request-URI are dependent on the nature of the
     1487   The four options for request-target are dependent on the nature of the
    14901488   request. The asterisk "*" means that the request does not apply to a
    14911489   particular resource, but to the server itself, and is only allowed
     
    15191517</t>
    15201518<t>
    1521    The most common form of Request-URI is that used to identify a
     1519   The most common form of request-target is that used to identify a
    15221520   resource on an origin server or gateway. In this case the absolute
    15231521   path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as
    1524    the Request-URI, and the network location of the URI (authority) &MUST;
     1522   the request-target, and the network location of the URI (authority) &MUST;
    15251523   be transmitted in a Host header field. For example, a client wishing
    15261524   to retrieve the resource above directly from the origin server would
     
    15381536</t>
    15391537<t>
    1540    The Request-URI is transmitted in the format specified in
    1541    <xref target="http.uri"/>. If the Request-URI is encoded using the
     1538   The request-target is transmitted in the format specified in
     1539   <xref target="http.uri"/>. If the request-target is encoded using the
    15421540   "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding
    15431541   (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server
    1544    &MUST; decode the Request-URI in order to
     1542   &MUST; decode the request-target in order to
    15451543   properly interpret the request. Servers &SHOULD; respond to invalid
    1546    Request-URIs with an appropriate status code.
     1544   request-targets with an appropriate status code.
    15471545</t>
    15481546<t>
    15491547   A transparent proxy &MUST-NOT; rewrite the "path-absolute" part of the
    1550    received Request-URI when forwarding it to the next inbound server,
     1548   received request-target when forwarding it to the next inbound server,
    15511549   except as noted above to replace a null path-absolute with "/".
    15521550</t>
     
    15571555      a non-reserved URI character for a reserved purpose.  Implementors
    15581556      should be aware that some pre-HTTP/1.1 proxies have been known to
    1559       rewrite the Request-URI.
     1557      rewrite the request-target.
    15601558  </t></list>
    15611559</t>
     1560<t>
     1561   HTTP does not place a pre-defined limit on the length of a request-target.
     1562   A server &MUST; be prepared to receive URIs of unbounded length and
     1563   respond with the 414 (URI too long) status if the received
     1564   request-target would be longer than the server wishes to handle
     1565   (see &status-414;).
     1566</t>
     1567<t>
     1568   Various ad-hoc limitations on request-target length are found in practice.
     1569   It is &RECOMMENDED; that all HTTP senders and recipients support
     1570   request-target lengths of 8000 or more OCTETs.
     1571</t>
    15621572</section>
    15631573</section>
     
    15661576<t>
    15671577   The exact resource identified by an Internet request is determined by
    1568    examining both the Request-URI and the Host header field.
     1578   examining both the request-target and the Host header field.
    15691579</t>
    15701580<t>
     
    15811591   resource on an HTTP/1.1 request:
    15821592  <list style="numbers">
    1583     <t>If Request-URI is an absolute-URI, the host is part of the
    1584      Request-URI. Any Host header field value in the request &MUST; be
     1593    <t>If request-target is an absolute-URI, the host is part of the
     1594     request-target. Any Host header field value in the request &MUST; be
    15851595     ignored.</t>
    1586     <t>If the Request-URI is not an absolute-URI, and the request includes
     1596    <t>If the request-target is not an absolute-URI, and the request includes
    15871597     a Host header field, the host is determined by the Host header
    15881598     field value.</t>
     
    28952905   other operating systems use ".." as a path component to indicate a
    28962906   directory level above the current one. On such a system, an HTTP
    2897    server &MUST; disallow any such construct in the Request-URI if it
     2907   server &MUST; disallow any such construct in the request-target if it
    28982908   would otherwise allow access to a resource outside those intended to
    28992909   be accessible via the HTTP server. Similarly, files intended for
     
    39523962   The requirements that clients and servers support the Host request-header,
    39533963   report an error if the Host request-header (<xref target="header.host"/>) is
    3954    missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-uri"/>)
     3964   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    39553965   are among the most important changes defined by this
    39563966   specification.
     
    40774087  Update use of abs_path production from RFC1808 to the path-absolute + query
    40784088  components of RFC3986.
    4079   (<xref target="request-uri"/>)
     4089  (<xref target="request-target"/>)
    40804090</t>
    40814091<t>
Note: See TracChangeset for help on using the changeset viewer.