Ignore:
Timestamp:
Mar 12, 2011, 10:51:57 PM (9 years ago)
Author:
fielding@…
Message:

editorial: clean up some of the language surrounding the URI
scheme definitions and request-target.

File:
1 edited

Legend:

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

    r1170 r1171  
    717717      <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
    718718         MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the
    719          Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate request targets and relationships between resources. Messages are passed in a format similar to that used by Internet
    720          mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
     719         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource and relationships between resources. Messages are passed in a format similar to that used
     720         by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
    721721      </p>
    722722      <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented
     
    927927         and response structures onto the data units of the underlying transport protocol is outside the scope of this specification.
    928928      </p>
    929       <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the identifier
    930          (if any) provided for the request target. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use
     929      <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's
     930         URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use
    931931         a proxy via some other connection port or protocol instead of using the defaults.
    932932      </p>
     
    10781078      </p>
    10791079      <p id="rfc.section.2.6.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",
    1080          "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.
     1080         "path-absolute", "query", and "authority" from the URI generic syntax <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 but not a fragment.
    10811081      </p>
    10821082      <div id="rfc.figure.u.18"></div><pre class="inline"><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><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, 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-4.1">Section 4.1</a>&gt;
     
    10921092  <a href="#uri" class="smpl">partial-URI</a>   = relative-part [ "?" query ]
    10931093</pre><p id="rfc.section.2.6.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
    1094          only a URI in absolute form (absolute-URI), any relative reference (relative-ref), or some other subset of the URI-reference
    1095          grammar. Unless otherwise indicated, URI references are parsed relative to the request target (the default base URI for both
    1096          the request and its corresponding response).
     1094         any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components,
     1095         or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request
     1096         URI, which defines the default base URI for references in both the request and its corresponding response.
    10971097      </p>
    10981098      <h3 id="rfc.section.2.6.1"><a href="#rfc.section.2.6.1">2.6.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
     
    11001100      <div id="rfc.iref.u.3"></div>
    11011101      <p id="rfc.section.2.6.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
    1102          namespace governed by a potential HTTP origin server listening for TCP connections on a given port. The HTTP server is identified
    1103          via the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port, and the remainder of the URI is considered to be identifying
    1104          data corresponding to a resource for which that server might provide an HTTP interface.
     1102         namespace governed by a potential HTTP origin server listening for TCP connections on a given port.
    11051103      </p>
    11061104      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.34"></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> ]
    1107 </pre><p id="rfc.section.2.6.1.p.3">The host identifier within an <a href="#uri" class="smpl">authority</a> component is 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.2.2">Section 3.2.2</a>. If host is provided as an IP literal or IPv4 address, then the HTTP server is any listener on the indicated TCP port at
    1108          that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might
    1109          use a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved
     1105</pre><p id="rfc.section.2.6.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<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.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an
     1106         identifier for a potential resource within that origin server's name space.
     1107      </p>
     1108      <p id="rfc.section.2.6.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated
     1109         TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient
     1110         might use a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved
    11101111         port for WWW services).
    11111112      </p>
    1112       <p id="rfc.section.2.6.1.p.4">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
     1113      <p id="rfc.section.2.6.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
    11131114         The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening
    11141115         to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish
     
    11161117         authority to determine which names are valid and how they might be used.
    11171118      </p>
    1118       <p id="rfc.section.2.6.1.p.5">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
     1119      <p id="rfc.section.2.6.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    11191120         and sending an HTTP request message to the server containing the URI's identifying data as described in <a href="#request" title="Request">Section&nbsp;4</a>. If the server responds to that request with a non-interim HTTP response message, as described in <a href="#response" title="Response">Section&nbsp;5</a>, then that response is considered an authoritative answer to the client's request.
    11201121      </p>
    1121       <p id="rfc.section.2.6.1.p.6">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     1122      <p id="rfc.section.2.6.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    11221123         delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
    11231124         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require
     
    11251126         — it is only the authoritative interface used for mapping the namespace that is specific to TCP.
    11261127      </p>
    1127       <p id="rfc.section.2.6.1.p.7">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<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.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
     1128      <p id="rfc.section.2.6.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<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.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
    11281129         configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
    11291130         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> include a userinfo subcomponent (and its "@" delimiter) when transmitting an "http" URI in a message. Recipients of HTTP messages
     
    11411142      </p>
    11421143      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    1143 </pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus are ineligible for shared caching.
    1144          Their default is "private" and might be further constrained via use of the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1144</pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP
     1145         or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    11451146      </p>
    11461147      <p id="rfc.section.2.6.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
    1147          only differ by the single "s" in the scheme name. They are different services governed by different authorities. However,
    1148          some extensions to HTTP that apply to entire host domains, such as the Cookie protocol, do allow one service to effect communication
    1149          with the other services based on host domain matching.
     1148         indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered
     1149         to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the
     1150         Cookie protocol <a href="#draft-ietf-httpstate-cookie" id="rfc.xref.draft-ietf-httpstate-cookie.1"><cite title="HTTP State Management Mechanism">[draft-ietf-httpstate-cookie]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains.
    11501151      </p>
    11511152      <p id="rfc.section.2.6.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
     
    11641165   http://EXAMPLE.com/%7Esmith/home.html
    11651166   http://EXAMPLE.com:/%7esmith/home.html
    1166 </pre><p id="rfc.section.2.6.3.p.5"> <span class="comment" id="TODO-not-here">[<a href="#TODO-not-here" class="smpl">TODO-not-here</a>: This paragraph does not belong here. --roy]</span> If path-abempty is the empty string (i.e., there is no slash "/" path separator following the authority), then the "http"
    1167          URI <em class="bcp14">MUST</em> be given as "/" when used as a request-target (<a href="#request-target" title="request-target">Section&nbsp;4.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.
    1168       </p>
    1169       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="http.message" href="#http.message">HTTP Message</a></h1>
     1167</pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="http.message" href="#http.message">HTTP Message</a></h1>
    11701168      <div id="rfc.iref.h.3"></div>
    11711169      <div id="rfc.iref.h.4"></div>
     
    12361234      <div class="note" id="rfc.section.3.2.p.7">
    12371235         <p> <b>Note:</b> The "Set-Cookie" header field as implemented in practice can occur multiple times, but does not use the list syntax, and thus
    1238             cannot be combined into a single line (<a href="#draft-ietf-httpstate-cookie" id="rfc.xref.draft-ietf-httpstate-cookie.1"><cite title="HTTP State Management Mechanism">[draft-ietf-httpstate-cookie]</cite></a>). (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
     1236            cannot be combined into a single line (<a href="#draft-ietf-httpstate-cookie" id="rfc.xref.draft-ietf-httpstate-cookie.2"><cite title="HTTP State Management Mechanism">[draft-ietf-httpstate-cookie]</cite></a>). (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
    12391237         </p>
    12401238      </div>
     
    14101408      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    14111409</pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
    1412       <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request.</p>
     1410      <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request. In most cases, the user agent is provided
     1411         a URI reference from which it determines an absolute URI for identifying the target resource. When a request to the resource
     1412         is initiated, all or part of that URI is used to construct the HTTP request-target.
     1413      </p>
    14131414      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
    14141415                 / <a href="#uri" class="smpl">absolute-URI</a>
     
    14161417                 / <a href="#uri" class="smpl">authority</a>
    14171418</pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request.</p>
    1418       <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.2"></span> The asterisk "*" ("asterisk form") means that the request does not apply to a particular resource, but to the server itself.
    1419          This is only allowed for the OPTIONS request method. Thus, the only valid example is
     1419      <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.2"></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
     1420         process) rather than to a specific named resource at that server. For example,
    14201421      </p>
    14211422      <div id="rfc.figure.u.31"></div><pre class="text2">OPTIONS * HTTP/1.1
    1422 </pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
    1423          and 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
    1424          loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example
    1425          Request-Line would be:
     1423</pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.3"></span> The "absolute-URI" form 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
     1424         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
     1425         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, and the numeric IP
     1426         address. An example Request-Line would be:
    14261427      </p>
    14271428      <div id="rfc.figure.u.32"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    14281429</pre><p id="rfc.section.4.1.2.p.8">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.
    14291430      </p>
    1430       <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    1431       </p>
    1432       <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.p.2"></span> The most common form of request-target is that used to identify a resource on an origin server or gateway ("path-absolute
    1433          form"). In this case the absolute path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.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
    1434          server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
     1431      <p id="rfc.section.4.1.2.p.9">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.
     1432      </p>
     1433      <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1434      </p>
     1435      <p id="rfc.section.4.1.2.p.11"><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 or gateway ("origin form").
     1436         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 <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified
     1437         above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and
     1438         send the lines:
    14351439      </p>
    14361440      <div id="rfc.figure.u.33"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
    14371441Host: www.example.org
    1438 </pre><p id="rfc.section.4.1.2.p.12">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
    1439          URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
    1440       </p>
    1441       <p id="rfc.section.4.1.2.p.13">If a proxy receives an OPTIONS request without any path in the request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
     1442</pre><p id="rfc.section.4.1.2.p.13">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path;
     1443         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.
     1444      </p>
     1445      <p id="rfc.section.4.1.2.p.14">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
     1446         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.
    14421447      </p>
    14431448      <div id="rfc.figure.u.34"></div>
     
    14471452Host: www.example.org:8001
    14481453</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
    1449       <p id="rfc.section.4.1.2.p.16">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-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.
    1450       </p>
    1451       <p id="rfc.section.4.1.2.p.17">A non-transforming 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
     1454      <p id="rfc.section.4.1.2.p.17">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-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.
     1455      </p>
     1456      <p id="rfc.section.4.1.2.p.18">A non-transforming 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
    14521457         above to replace a null path-absolute with "/" or "*".
    14531458      </p>
    1454       <div class="note" id="rfc.section.4.1.2.p.18">
     1459      <div class="note" id="rfc.section.4.1.2.p.19">
    14551460         <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
    14561461            a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been
     
    14581463         </p>
    14591464      </div>
    1460       <p id="rfc.section.4.1.2.p.19">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 code if the received request-target
     1465      <p id="rfc.section.4.1.2.p.20">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 code if the received request-target
    14611466         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    14621467      </p>
    1463       <p id="rfc.section.4.1.2.p.20">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.
    1464       </p>
    1465       <div class="note" id="rfc.section.4.1.2.p.21">
     1468      <p id="rfc.section.4.1.2.p.21">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.
     1469      </p>
     1470      <div class="note" id="rfc.section.4.1.2.p.22">
    14661471         <p> <b>Note:</b> Fragments (<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-3.5">Section 3.5</a>) are not part of the request-target and thus will not be transmitted in an HTTP request.
    14671472         </p>
     
    36133618                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">6.2.2.2</a></li>
    36143619                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li>
    3615                   <li><em>draft-ietf-httpstate-cookie</em>&nbsp;&nbsp;<a href="#rfc.xref.draft-ietf-httpstate-cookie.1">3.2</a>, <a href="#draft-ietf-httpstate-cookie"><b>13.2</b></a></li>
     3620                  <li><em>draft-ietf-httpstate-cookie</em>&nbsp;&nbsp;<a href="#rfc.xref.draft-ietf-httpstate-cookie.1">2.6.2</a>, <a href="#rfc.xref.draft-ietf-httpstate-cookie.2">3.2</a>, <a href="#draft-ietf-httpstate-cookie"><b>13.2</b></a></li>
    36163621               </ul>
    36173622            </li>
     
    37943799            </li>
    37953800            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
     3801                  <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">4.1.2</a></li>
    37963802                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
    37973803                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
     
    38243830                     </ul>
    38253831                  </li>
    3826                   <li>path-absolute form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.p.2">4.1.2</a></li>
    38273832                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
    38283833               </ul>
Note: See TracChangeset for help on using the changeset viewer.