Changeset 1171


Ignore:
Timestamp:
13/03/11 06:51:57 (9 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 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>

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

    r1170 r1171  
    229229   message payloads for flexible interaction with network-based hypertext
    230230   information systems. HTTP relies upon the Uniform Resource Identifier (URI)
    231    standard <xref target="RFC3986"/> to indicate request targets and
     231   standard <xref target="RFC3986"/> to indicate the target resource and
    232232   relationships between resources.
    233233   Messages are passed in a format similar to that used by Internet mail
    … …  
    625625<t>
    626626   The specific connection protocols to be used for an interaction
    627    are determined by client configuration and the identifier (if any)
    628    provided for the request target.  For example, the "http" URI scheme
     627   are determined by client configuration and the target resource's URI.
     628   For example, the "http" URI scheme
    629629   (<xref target="http.uri"/>) indicates a default connection of TCP
    630630   over IP, with a default TCP port of 80, but the client might be
    … …  
    942942   This specification adopts the definitions of "URI-reference",
    943943   "absolute-URI", "relative-part", "port", "host",
    944    "path-abempty", "path-absolute", "query", and "authority" from
    945    <xref target="RFC3986"/>. In addition, we define a partial-URI rule for
    946    protocol elements that allow a relative URI without a fragment.
     944   "path-abempty", "path-absolute", "query", and "authority" from the
     945   URI generic syntax <xref target="RFC3986"/>.
     946   In addition, we define a partial-URI rule for protocol elements
     947   that allow a relative URI but not a fragment.
    947948</t>
    948949<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"/>
    … …  
    960961</artwork></figure>
    961962<t>
    962    Each protocol element in HTTP that allows a URI reference will indicate in
    963    its ABNF production whether the element allows only a URI in absolute form
    964    (absolute-URI), any relative reference (relative-ref), or some other subset
    965    of the URI-reference grammar. Unless otherwise indicated, URI references
    966    are parsed relative to the request target (the default base URI for both
    967    the request and its corresponding response).
     963   Each protocol element in HTTP that allows a URI reference will indicate
     964   in its ABNF production whether the element allows any form of reference
     965   (URI-reference), only a URI in absolute form (absolute-URI), only the
     966   path and optional query components, or some combination of the above.
     967   Unless otherwise indicated, URI references are parsed relative to the
     968   effective request URI, which defines the default base URI for references
     969   in both the request and its corresponding response.
    968970</t>
    969971
    … …  
    977979   namespace governed by a potential HTTP origin server listening for
    978980   TCP connections on a given port.
    979    The HTTP server is identified via the generic syntax's
    980    <x:ref>authority</x:ref> component, which includes a host
    981    identifier and optional TCP port, and the remainder of the URI is
    982    considered to be identifying data corresponding to a resource for
    983    which that server might provide an HTTP interface.
    984981</t>
    985982<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/>
    … …  
    987984</artwork></figure>
    988985<t>
    989    The host identifier within an <x:ref>authority</x:ref> component is
    990    defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>.  If host is
    991    provided as an IP literal or IPv4 address, then the HTTP server is any
    992    listener on the indicated TCP port at that IP address. If host is a
    993    registered name, then that name is considered an indirect identifier
    994    and the recipient might use a name resolution service, such as DNS,
    995    to find the address of a listener for that host.
     986   The HTTP origin server is identified by the generic syntax's
     987   <x:ref>authority</x:ref> component, which includes a host identifier
     988   and optional TCP port (<xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>).
     989   The remainder of the URI, consisting of both the hierarchical path
     990   component and optional query component, serves as an identifier for
     991   a potential resource within that origin server's name space.
     992</t>
     993<t>
     994   If the host identifier is provided as an IP literal or IPv4 address,
     995   then the origin server is any listener on the indicated TCP port at
     996   that IP address. If host is a registered name, then that name is
     997   considered an indirect identifier and the recipient might use a name
     998   resolution service, such as DNS, to find the address of a listener
     999   for that host.
    9961000   The host &MUST-NOT; be empty; if an "http" URI is received with an
    9971001   empty host, then it &MUST; be rejected as invalid.
    … …  
    10701074<t>
    10711075   Unlike the "http" scheme, responses to "https" identified requests
    1072    are never "public" and thus are ineligible for shared caching.
    1073    Their default is "private" and might be further constrained via use
    1074    of the Cache-Control header field (&header-cache-control;).
     1076   are never "public" and thus &MUST-NOT; be reused for shared caching.
     1077   They can, however, be reused in a private cache if the message is
     1078   cacheable by default in HTTP or specifically indicated as such by
     1079   the Cache-Control header field (&header-cache-control;).
    10751080</t>
    10761081<t>
    10771082   Resources made available via the "https" scheme have no shared
    10781083   identity with the "http" scheme even if their resource identifiers
    1079    only differ by the single "s" in the scheme name.  They are
    1080    different services governed by different authorities.  However,
    1081    some extensions to HTTP that apply to entire host domains, such
    1082    as the Cookie protocol, do allow one service to effect communication
    1083    with the other services based on host domain matching.
     1084   indicate the same authority (the same host listening to the same
     1085   TCP port).  They are distinct name spaces and are considered to be
     1086   distinct origin servers.  However, an extension to HTTP that is
     1087   defined to apply to entire host domains, such as the Cookie protocol
     1088   <xref target="draft-ietf-httpstate-cookie"/>, can allow information
     1089   set by one service to impact communication with other services
     1090   within a matching group of host domains.
    10841091</t>
    10851092<t>
    … …  
    11151122   http://EXAMPLE.com:/%7esmith/home.html
    11161123</artwork></figure>
    1117 <t>
    1118    <cref anchor="TODO-not-here" source="roy">This paragraph does not belong here.</cref>
    1119    If path-abempty is the empty string (i.e., there is no slash "/"
    1120    path separator following the authority), then the "http" URI
    1121    &MUST; be given as "/" when
    1122    used as a request-target (<xref target="request-target"/>). If a proxy
    1123    receives a host name which is not a fully qualified domain name, it
    1124    &MAY; add its domain to the host name it received. If a proxy receives
    1125    a fully qualified domain name, the proxy &MUST-NOT; change the host
    1126    name.
    1127 </t>
    11281124</section>
    11291125</section>
    … …  
    15821578  <x:anchor-alias value="request-target"/>
    15831579<t>
    1584    The request-target identifies the target resource upon which to apply the request.
     1580   The request-target identifies the target resource upon which to apply
     1581   the request.  In most cases, the user agent is provided a URI reference
     1582   from which it determines an absolute URI for identifying the target
     1583   resource.  When a request to the resource is initiated, all or part
     1584   of that URI is used to construct the HTTP request-target.
    15851585</t>
    15861586<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/>
    … …  
    15951595</t>   
    15961596<t><iref item="asterisk form (of request-target)"/>
    1597    The asterisk "*" ("asterisk form") means that the request does not apply to a
    1598    particular resource, but to the server itself. This is only allowed for the
    1599    OPTIONS request method. Thus, the only valid example is
     1597   The asterisk "*" form of request-target, which &MUST-NOT; be used
     1598   with any request method other than OPTIONS, means that the request
     1599   applies to the server as a whole (the listening process) rather than
     1600   to a specific named resource at that server.  For example,
    16001601</t>
    16011602<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    16041605<t><iref item="absolute-URI form (of request-target)"/>
    16051606   The "absolute-URI" form is &REQUIRED; when the request is being made to a
    1606    proxy. The proxy is requested to forward the request or service it
    1607    from a valid cache, and return the response. Note that the proxy &MAY;
     1607   proxy. The proxy is requested to either forward the request or service it
     1608   from a valid cache, and then return the response. Note that the proxy &MAY;
    16081609   forward the request on to another proxy or directly to the server
    16091610   specified by the absolute-URI. In order to avoid request loops, a
    1610    proxy &MUST; be able to recognize all of its server names, including
     1611   proxy that forwards requests to other proxies &MUST; be able to
     1612   recognize and exclude all of its own server names, including
    16111613   any aliases, local variations, and the numeric IP address. An example
    16121614   Request-Line would be:
    … …  
    16211623   them in requests to proxies.
    16221624</t>
     1625<t>
     1626   If a proxy receives a host name that is not a fully qualified domain
     1627   name, it &MAY; add its domain to the host name it received. If a proxy
     1628   receives a fully qualified domain name, the proxy &MUST-NOT; change
     1629   the host name.
     1630</t>
    16231631<t><iref item="authority form (of request-target)"/>
    16241632   The "authority form" is only used by the CONNECT request method (&CONNECT;).
    16251633</t>
    1626 <t><iref item="path-absolute form (of request-target)"/>
    1627    The most common form of request-target is that used to identify a
    1628    resource on an origin server or gateway ("path-absolute form"). In this case the absolute
    1629    path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as
    1630    the request-target, and the network location of the URI (authority) &MUST;
    1631    be transmitted in a Host header field. For example, a client wishing
    1632    to retrieve the resource above directly from the origin server would
    1633    create a TCP connection to port 80 of the host "www.example.org" and send
    1634    the lines:
     1634<t><iref item="origin form (of request-target)"/>
     1635   The most common form of request-target is that used when making
     1636   a request to an origin server or gateway ("origin form").
     1637   In this case, the absolute path and query components of the URI
     1638   &MUST; be transmitted as the request-target, and the authority component
     1639   &MUST; be transmitted in a Host header field. For example, a client wishing
     1640   to retrieve a representation of the resource, as identified above,
     1641   directly from the origin server would open (or reuse) a TCP connection
     1642   to port 80 of the host "www.example.org" and send the lines:
    16351643</t>
    16361644<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    16391647</artwork></figure>
    16401648<t>
    1641    followed by the remainder of the Request. Note that the absolute path
    1642    cannot be empty; if none is present in the original URI, it &MUST; be
    1643    given as "/" (the server root).
    1644 </t>
    1645 <t>
    1646    If a proxy receives an OPTIONS request without any path in the
    1647    request-target, then the last proxy on the request chain &MUST;
    1648    forward the request with "*" as the final request-target.
     1649   followed by the remainder of the Request. Note that the origin form
     1650   of request-target always starts with an absolute path; if the target
     1651   resource's URI path is empty, then an absolute path of "/" &MUST; be
     1652   provided in the request-target.
     1653</t>
     1654<t>
     1655   If a proxy receives an OPTIONS request with an absolute-URI form of
     1656   request-target in which the URI has an empty path and no query component,
     1657   then the last proxy on the request chain &MUST; use a request-target
     1658   of "*" when it forwards the request to the indicated origin server.
    16491659</t>
    16501660<figure><preamble>   
Note: See TracChangeset for help on using the changeset viewer.