![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 991 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- Sep 6, 2010, 8:38:00 AM (9 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (11 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r983 r991 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 2">406 <meta name="dct.issued" scheme="ISO8601" content="2010-09-06"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: March 6, 2011</td>437 <td class="left">Expires: March 10, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">September 2, 2010</td>490 <td class="right">September 6, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </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> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1341 1341 / <a href="#uri" class="smpl">authority</a> 1342 1342 </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 allowed1344 when the method used does not necessarily apply to a resource. One example would be1343 <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 1345 1345 </p> 1346 1346 <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, 1348 1348 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 1349 1349 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 … … 1353 1353 </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. 1354 1354 </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 the1358 absolute path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section 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 origin1355 <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 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 1359 1359 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1360 1360 </p> … … 1422 1422 </p> 1423 1423 <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> 1427 1425 <p id="rfc.section.4.3.p.4"> </p> 1428 1426 <ul> … … 1431 1429 </li> 1432 1430 <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 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 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 4.2</a>? -- See <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/221">http://tools.ietf.org/wg/httpbis/trac/ticket/221</a>> --jre]</span> and1431 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 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 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 4.2</a>? -- See <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/221">http://tools.ietf.org/wg/httpbis/trac/ticket/221</a>> --jre]</span> and 1434 1432 </li> 1435 1433 <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> … … 2433 2431 </dl> 2434 2432 <div id="rfc.iref.m.4"></div> 2435 <div id="rfc.iref.a. 1"></div>2433 <div id="rfc.iref.a.4"></div> 2436 2434 <h3 id="rfc.section.10.3.2"><a href="#rfc.section.10.3.2">10.3.2</a> <a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3> 2437 2435 <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> … … 3458 3456 <ul class="ind"> 3459 3457 <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 <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) <a class="iref" href="#rfc.iref.a.2">4.1.2</a></li> 3459 <li class="indline1">application/http Media Type <a class="iref" href="#rfc.iref.a.4"><b>10.3.2</b></a></li> 3460 <li class="indline1">asterisk form (of request-target) <a class="iref" href="#rfc.iref.a.1">4.1.2</a></li> 3461 <li class="indline1">authority form (of request-target) <a class="iref" href="#rfc.iref.a.3">4.1.2</a></li> 3461 3462 </ul> 3462 3463 </li> … … 3703 3704 </ul> 3704 3705 </li> 3706 <li class="indline1">path-absolute form (of request-target) <a class="iref" href="#rfc.iref.p.2">4.1.2</a></li> 3705 3707 <li class="indline1">proxy <a class="iref" href="#rfc.iref.p.1"><b>2.2</b></a></li> 3706 3708 </ul>
Note: See TracChangeset
for help on using the changeset viewer.
