Source: https://trac.ietf.org/trac/httpbis/changeset/809/draft-ietf-httpbis
Timestamp: 2020-08-13 15:21:53
Document Index: 6258683

Matched Legal Cases: ['art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2']

Changeset 809 for draft-ietf-httpbis – Hypertext Transfer Protocol Wiki
Changeset 809 for draft-ietf-httpbis
13/04/10 13:20:33 (10 years ago)
add paragraph break for clarity (related to #196)
<meta name="dct.issued" scheme="ISO8601" content="2010-04-11">
<meta name="dct.issued" scheme="ISO8601" content="2010-04-13">
<td class="left">Expires: October 13, 2010</td>
<td class="left">Expires: October 15, 2010</td>
<td class="right">April 11, 2010</td>
<td class="right">April 13, 2010</td>
<p>This Internet-Draft will expire in October 13, 2010.</p>
<p>This Internet-Draft will expire in October 15, 2010.</p>
/ <a href="#uri" class="smpl">authority</a>
</pre><p id="rfc.section.4.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
not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
apply to a resource. One example would be
</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>
<p id="rfc.section.4.1.2.p.4">The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One example would be
<div id="rfc.figure.u.35"></div><pre class="text2">OPTIONS * HTTP/1.1
</pre><p id="rfc.section.4.1.2.p.5">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,
</pre><p id="rfc.section.4.1.2.p.6">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,
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
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
<div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
</pre><p id="rfc.section.4.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.
<p id="rfc.section.4.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
<p id="rfc.section.4.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
</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.
<p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
<p id="rfc.section.4.1.2.p.10">The most common form of request-target is that used to identify a resource on an origin server or gateway. 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
server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
<div id="rfc.figure.u.37"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
</pre><p id="rfc.section.4.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
</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
URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
<p id="rfc.section.4.1.2.p.12">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the
<p id="rfc.section.4.1.2.p.13">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the
asterisk form of request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
</pre> <p>after connecting to port 8001 of host "www.example.org".</p>
<p id="rfc.section.4.1.2.p.15">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.17"><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.
<p id="rfc.section.4.1.2.p.16">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
<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.17"><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.
<p id="rfc.section.4.1.2.p.17">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
above to replace a null path-absolute with "/".
<div class="note" id="rfc.section.4.1.2.p.17">
<div class="note" id="rfc.section.4.1.2.p.18">
<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
a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
<p id="rfc.section.4.1.2.p.18">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
<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 if the received request-target
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.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
<p id="rfc.section.4.1.2.p.19">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.
<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.
<h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.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>
The four options for request-target are dependent on the nature of the
The asterisk "*" means that the request does not apply to a