Ignore:
Timestamp:
Sep 6, 2010, 8:38:00 AM (9 years ago)
Author:
julian.reschke@…
Message:

introduce the terms "path-absolute form" and "asterisk form" (of request-target) (related to #221)

File:
1 edited

Legend:

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

    r983 r991  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-09-02">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-09-06">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
     
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: March 6, 2011</td>
     437               <td class="left">Expires: March 10, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">September 2, 2010</td>
     490               <td class="right">September 6, 2010</td>
    491491            </tr>
    492492         </tbody>
     
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on March 6, 2011.</p>
     518      <p>This Internet-Draft will expire on March 10, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    13411341                 / <a href="#uri" class="smpl">authority</a>
    13421342</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>
    1343       <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
    1344          when the method used does not necessarily apply to a resource. One example would be
     1343      <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.1"></span> The asterisk "*" ("asterisk form") means that the request does not apply to a particular resource, but to the server itself,
     1344         and is only allowed when the method used does not necessarily apply to a resource. One example would be
    13451345      </p>
    13461346      <div id="rfc.figure.u.35"></div><pre class="text2">OPTIONS * HTTP/1.1
    1347 </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,
     1347</pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.2"></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,
    13481348         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
    13491349         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
     
    13531353</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.
    13541354      </p>
    1355       <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.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    1356       </p>
    1357       <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
    1358          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
     1355      <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> 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.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1356      </p>
     1357      <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
     1358         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
    13591359         server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
    13601360      </p>
     
    14221422      </p>
    14231423      <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p>
    1424       <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the effective
    1425          request URI is constructed by concatenating
    1426       </p>
     1424      <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute form or the asterisk form, then the effective request URI is constructed by concatenating</p>
    14271425      <p id="rfc.section.4.3.p.4"> </p>
    14281426      <ul>
     
    14311429         </li>
    14321430         <li>the character sequence "://",</li>
    1433          <li>the authority component, as specified in the Host header (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;9.4</a>) and determined by the rules in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section&nbsp;4.2</a>, <span class="comment" id="effrequri-nohost">[<a href="#effrequri-nohost" class="smpl">effrequri-nohost</a>: Do we need to include the handling of missing hosts in HTTP/1.0 messages, as described in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section&nbsp;4.2</a>? -- See &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/221">http://tools.ietf.org/wg/httpbis/trac/ticket/221</a>&gt; --jre]</span> and
     1431         <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;9.4</a>) and determined by the rules in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section&nbsp;4.2</a>, <span class="comment" id="effrequri-nohost">[<a href="#effrequri-nohost" class="smpl">effrequri-nohost</a>: Do we need to include the handling of missing hosts in HTTP/1.0 messages, as described in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section&nbsp;4.2</a>? -- See &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/221">http://tools.ietf.org/wg/httpbis/trac/ticket/221</a>&gt; --jre]</span> and
    14341432         </li>
    14351433         <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li>
     
    24332431      </dl>
    24342432      <div id="rfc.iref.m.4"></div>
    2435       <div id="rfc.iref.a.1"></div>
     2433      <div id="rfc.iref.a.4"></div>
    24362434      <h3 id="rfc.section.10.3.2"><a href="#rfc.section.10.3.2">10.3.2</a>&nbsp;<a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3>
    24372435      <p id="rfc.section.10.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p>
     
    34583456         <ul class="ind">
    34593457            <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind">
    3460                   <li class="indline1">application/http Media Type&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.1"><b>10.3.2</b></a></li>
     3458                  <li class="indline1">absolute-URI form (of request-target)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.2">4.1.2</a></li>
     3459                  <li class="indline1">application/http Media Type&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.4"><b>10.3.2</b></a></li>
     3460                  <li class="indline1">asterisk form (of request-target)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.1">4.1.2</a></li>
     3461                  <li class="indline1">authority form (of request-target)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.3">4.1.2</a></li>
    34613462               </ul>
    34623463            </li>
     
    37033704                     </ul>
    37043705                  </li>
     3706                  <li class="indline1">path-absolute form (of request-target)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.2">4.1.2</a></li>
    37053707                  <li class="indline1">proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>2.2</b></a></li>
    37063708               </ul>
Note: See TracChangeset for help on using the changeset viewer.