Changeset 809 for draft-ietf-httpbis/latest
- Timestamp:
- 13/04/10 13:20:33 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r808 r809 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-04-1 1">406 <meta name="dct.issued" scheme="ISO8601" content="2010-04-13"> 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: October 1 3, 2010</td>437 <td class="left">Expires: October 15, 2010</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">April 1 1, 2010</td>490 <td class="right">April 13, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire in October 1 3, 2010.</p>518 <p>This Internet-Draft will expire in October 15, 2010.</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> … … 1308 1308 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) 1309 1309 / <a href="#uri" class="smpl">authority</a> 1310 </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 does1311 not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily1312 apply to a resource. One example would be1310 </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> 1311 <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 1312 when the method used does not necessarily apply to a resource. One example would be 1313 1313 </p> 1314 1314 <div id="rfc.figure.u.35"></div><pre class="text2">OPTIONS * HTTP/1.1 1315 </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,1315 </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, 1316 1316 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 1317 1317 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 … … 1319 1319 </p> 1320 1320 <div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1321 </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.1322 </p> 1323 <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>).1324 </p> 1325 <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 the1321 </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. 1322 </p> 1323 <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>). 1324 </p> 1325 <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 1326 1326 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 1327 1327 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: … … 1329 1329 <div id="rfc.figure.u.37"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1 1330 1330 Host: www.example.org 1331 </pre><p id="rfc.section.4.1.2.p.1 1">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original1331 </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 1332 1332 URI, it <em class="bcp14">MUST</em> be given as "/" (the server root). 1333 1333 </p> 1334 <p id="rfc.section.4.1.2.p.1 2">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the1334 <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 1335 1335 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. 1336 1336 </p> … … 1341 1341 Host: www.example.org:8001 1342 1342 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> 1343 <p id="rfc.section.4.1.2.p.1 5">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 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.1344 </p> 1345 <p id="rfc.section.4.1.2.p.1 6">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 noted1343 <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 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. 1344 </p> 1345 <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 1346 1346 above to replace a null path-absolute with "/". 1347 1347 </p> 1348 <div class="note" id="rfc.section.4.1.2.p.1 7">1348 <div class="note" id="rfc.section.4.1.2.p.18"> 1349 1349 <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 1350 1350 a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been … … 1352 1352 </p> 1353 1353 </div> 1354 <p id="rfc.section.4.1.2.p.1 8">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-target1354 <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 1355 1355 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>). 1356 1356 </p> 1357 <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.1357 <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. 1358 1358 </p> 1359 1359 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> -
draft-ietf-httpbis/latest/p1-messaging.xml
r808 r809 1441 1441 <t> 1442 1442 The four options for request-target are dependent on the nature of the 1443 request. The asterisk "*" means that the request does not apply to a 1443 request. 1444 </t> 1445 <t> 1446 The asterisk "*" means that the request does not apply to a 1444 1447 particular resource, but to the server itself, and is only allowed 1445 1448 when the method used does not necessarily apply to a resource. One
Note: See TracChangeset
for help on using the changeset viewer.