Changeset 1162
- Timestamp:
- Mar 10, 2011, 9:42:12 PM (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1159 r1162 1291 1291 <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and 1292 1292 the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 5.1.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g., 1293 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the method had been GET. All 1xx1294 (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.1293 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1294 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length. 1295 1295 </p> 1296 1296 <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p> … … 1432 1432 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a> 1433 1433 </pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="method" href="#method">Method</a></h3> 1434 <p id="rfc.section.4.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. Themethod is case-sensitive.</p>1434 <p id="rfc.section.4.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1435 1435 <div id="rfc.figure.u.32"></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> 1436 1436 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1437 <p id="rfc.section.4.1.2.p.1">The request-target identifies the resource upon which to apply the request.</p>1437 <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request.</p> 1438 1438 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1439 1439 / <a href="#uri" class="smpl">absolute-URI</a> … … 1442 1442 </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> 1443 1443 <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. 1444 This is only allowed for the OPTIONS method. Thus, the only valid example is1444 This is only allowed for the OPTIONS request method. Thus, the only valid example is 1445 1445 </p> 1446 1446 <div id="rfc.figure.u.34"></div><pre class="text2">OPTIONS * HTTP/1.1 … … 1453 1453 </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. 1454 1454 </p> 1455 <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>).1455 <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 request 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>). 1456 1456 </p> 1457 1457 <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 … … 1464 1464 URI, it <em class="bcp14">MUST</em> be given as "/" (the server root). 1465 1465 </p> 1466 <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 1467 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. 1466 <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. 1468 1467 </p> 1469 1468 <div id="rfc.figure.u.37"></div> 1470 1469 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1471 1470 </pre><div id="rfc.figure.u.38"></div> 1472 <p>would be forwarded by the proxy as</p><pre class="text2">OPTIONS * HTTP/1.11471 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1473 1472 Host: www.example.org:8001 1474 1473 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> … … 1890 1889 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1891 1890 </p> 1892 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences ofmethods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1891 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1893 1892 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 1894 1893 </p> … … 1974 1973 </p> 1975 1974 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1976 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding1975 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1977 1976 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1978 1977 </p> … … 2021 2020 <ul> 2022 2021 <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status 2023 code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request edmethod if it returns a final status code.2022 code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. 2024 2023 </li> 2025 2024 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" … … 2134 2133 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2> 2135 2134 <p id="rfc.section.9.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other 2136 than a response to the HEAD method or a response with a status code of 304. In the case of responses to the HEAD method, it2135 than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length 2137 2136 indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request 2138 been a GET. In the case of the 304 (Not Modified) response, it indicates the size of the payload body (not including any potential2139 transfer-coding) that would have been sent in a 200 (OK) response.2137 been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload 2138 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 2140 2139 </p> 2141 2140 <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> … … 2310 2309 transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol 2311 2310 while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by 2312 the server, possibly according to the nature of the method and/or resource being requested).2311 the server, possibly according to the nature of the request method or target resource). 2313 2312 </p> 2314 2313 <p id="rfc.section.9.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. … … 2999 2998 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 3000 2999 <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred 3001 to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single method and no metadata.3002 HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers3000 to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request method (GET) 3001 and no metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers 3003 3002 on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical 3004 3003 proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented … … 3084 3083 </p> 3085 3084 <p id="rfc.section.B.3.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk 3086 form is allowed for the OPTIONS method only. (<a href="#request-target" title="request-target">Section 4.1.2</a>)3085 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section 4.1.2</a>) 3087 3086 </p> 3088 3087 <p id="rfc.section.B.3.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore -
draft-ietf-httpbis/latest/p2-semantics.html
r1160 r1162 774 774 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>> 775 775 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 776 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.776 <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 777 777 </p> 778 778 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method" class="smpl">Method</a> = <a href="#core.rules" class="smpl">token</a> … … 829 829 </table> 830 830 </div> 831 <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include methods defined in other specifications.</p>831 <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include request methods defined in other specifications.</p> 832 832 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="method.registry" href="#method.registry">Method Registry</a></h2> 833 833 <p id="rfc.section.2.2.p.1">The HTTP Method Registry defines the name space for the Method token in the Request line of an HTTP request.</p> … … 1309 1309 </p> 1310 1310 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> 1311 <p id="rfc.section.7.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed1312 to share the same semantics for separately extended clients and servers.1311 <p id="rfc.section.7.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot 1312 be assumed to share the same semantics for separately extended clients and servers. 1313 1313 </p> 1314 1314 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> … … 1318 1318 the user to be aware of any actions they take which might have an unexpected significance to themselves or others. 1319 1319 </p> 1320 <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. Thesemethods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is1320 <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is 1321 1321 made aware of the fact that a possibly unsafe action is being requested. 1322 1322 </p> … … 1327 1327 <div id="rfc.iref.i.1"></div> 1328 1328 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 1329 <p id="rfc.section.7.1.2.p.1"> Methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect of1330 multiple identical requests is the same as for a single request. The methods PUT, DELETE, and all safemethods are idempotent.1329 <p id="rfc.section.7.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect 1330 of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. 1331 1331 It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state 1332 1332 due to multiple requests for the purpose of tracking those requests, versioning of results, etc. … … 1335 1335 <div id="rfc.iref.o.1"></div> 1336 1336 <div id="rfc.iref.m.1"></div> 1337 <p id="rfc.section.7.2.p.1">The OPTIONS method re presents a request for information about the communication options available on the request/response1338 chain identified by the effective request URI. This method allows the client to determine the options and/or requirements1339 associated with a resource,or the capabilities of a server, without implying a resource action or initiating a resource retrieval.1340 </p> 1341 <p id="rfc.section.7.2.p.2">Responses to th ismethod are not cacheable.</p>1337 <p id="rfc.section.7.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 1338 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 1339 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 1340 </p> 1341 <p id="rfc.section.7.2.p.2">Responses to the OPTIONS method are not cacheable.</p> 1342 1342 <p id="rfc.section.7.2.p.3">If the OPTIONS request includes a message-body (as indicated by the presence of Content-Length or Transfer-Encoding), then 1343 1343 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions … … 1361 1361 <div id="rfc.iref.g.5"></div> 1362 1362 <div id="rfc.iref.m.2"></div> 1363 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds tothe target resource.</p>1363 <p id="rfc.section.7.3.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1364 1364 <p id="rfc.section.7.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation 1365 1365 in the response and not the source text of the process, unless that text happens to be the output of the process. 1366 1366 </p> 1367 1367 <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, 1368 If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the representation be transferred1369 only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce1370 unnecessary network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring1371 dataalready held by the client.1368 If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only 1369 under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary 1370 network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data 1371 already held by the client. 1372 1372 </p> 1373 1373 <p id="rfc.section.7.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial 1374 GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved representations to1375 be completed without transferring data already held by the client.1374 GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations 1375 to be completed without transferring data already held by the client. 1376 1376 </p> 1377 1377 <p id="rfc.section.7.3.p.5">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). … … 1393 1393 <div id="rfc.iref.m.4"></div> 1394 1394 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="POST" href="#POST">POST</a></h2> 1395 <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be1396 processedby the target resource. POST is designed to allow a uniform method to cover the following functions:1395 <p id="rfc.section.7.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed 1396 by the target resource. POST is designed to allow a uniform method to cover the following functions: 1397 1397 </p> 1398 1398 <ul> … … 1420 1420 <div id="rfc.iref.m.5"></div> 1421 1421 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 1422 <p id="rfc.section.7.6.p.1">The PUT method is used to request that the state of the target resource be created or replaced with the state defined by the1423 representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent1424 GET on that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However,1425 there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other1426 user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received.1427 A successfulresponse only implies that the user agent's intent was achieved at the time of its processing by the origin server.1422 <p id="rfc.section.7.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 1423 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1424 that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there 1425 is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents 1426 in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful 1427 response only implies that the user agent's intent was achieved at the time of its processing by the origin server. 1428 1428 </p> 1429 1429 <p id="rfc.section.7.6.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that … … 1494 1494 <div id="rfc.iref.t.1"></div> 1495 1495 <div id="rfc.iref.m.7"></div> 1496 <p id="rfc.section.7.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the 1497 request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either 1496 <p id="rfc.section.7.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either 1498 1497 the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body. 1499 1498 </p> … … 1508 1507 <div id="rfc.iref.m.8"></div> 1509 1508 <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> 1510 <p id="rfc.section.7.9.p.1">The CONNECT method is used with a proxy to dynamically switch the connection to a tunnel.</p> 1511 <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> be use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the host name and port number destination of the requested connection separated by a colon: 1509 <p id="rfc.section.7.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and then restrict its behavior to blind 1510 forwarding of packets until the connection is closed. 1511 </p> 1512 <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1513 For example, 1512 1514 </p> 1513 1515 <div id="rfc.figure.u.10"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 … … 1890 1892 <div id="rfc.iref.s.34"></div> 1891 1893 <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> 1892 <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the re presentation of the request is in a format not supported by the1893 target resource for the requested method.1894 <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method 1895 on the target resource. 1894 1896 </p> 1895 1897 <div id="rfc.iref.55"></div> … … 1972 1974 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 1973 1975 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of 1974 this field is strictly to inform the recipient of valid methods associated with the resource.1976 this field is strictly to inform the recipient of valid request methods associated with the resource. 1975 1977 </p> 1976 1978 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a> … … 2073 2075 <p id="rfc.section.9.5.p.4">Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). 2074 2076 </p> 2075 <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other methods.2077 <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. 2076 2078 </p> 2077 2079 <div id="rfc.iref.r.1"></div> … … 2158 2160 </pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2159 2161 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> 2160 <p id="rfc.section.10.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document.2162 <p id="rfc.section.10.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document. 2161 2163 </p> 2162 2164 <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: … … 2582 2584 to uniquely identify the user. 2583 2585 </p> 2584 <p id="rfc.section.11.1.p.9">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentialsand other header fields that might be used2586 <p id="rfc.section.11.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used 2585 2587 to collect data from the client. 2586 2588 </p> -
draft-ietf-httpbis/latest/p3-payload.html
r1154 r1162 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 0, 2011";361 content: "Expires September 11, 2011"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-03- 09">410 <meta name="dct.issued" scheme="ISO8601" content="2011-03-10"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: September 1 0, 2011</td>436 <td class="left">Expires: September 11, 2011</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 491 491 <tr> 492 492 <td class="left"></td> 493 <td class="right">March 9, 2011</td>493 <td class="right">March 10, 2011</td> 494 494 </tr> 495 495 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on September 1 0, 2011.</p>519 <p>This Internet-Draft will expire on September 11, 2011.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1329 1329 <p id="rfc.section.6.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response 1330 1330 payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 1331 when no Content-Location is provided by the server. For a state-changing methodlike PUT or POST, it implies that the server's1331 when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's 1332 1332 response contains the new representation of that resource, thereby distinguishing it from representations that might only 1333 1333 report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the … … 1339 1339 and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location 1340 1340 indicates that this representation contains a report on the action's status and the same report is available (for future access 1341 with GET) at the given URI. For example, a purchase transaction made via the POST method might include a receipt document1342 asthe payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt1341 with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as 1342 the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt 1343 1343 in the future. 1344 1344 </p> -
draft-ietf-httpbis/latest/p4-conditional.html
r1155 r1162 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 0, 2011";361 content: "Expires September 11, 2011"; 362 362 } 363 363 @bottom-right { … … 406 406 <meta name="dct.creator" content="Reschke, J. F."> 407 407 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 408 <meta name="dct.issued" scheme="ISO8601" content="2011-03- 09">408 <meta name="dct.issued" scheme="ISO8601" content="2011-03-10"> 409 409 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 410 410 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 432 432 </tr> 433 433 <tr> 434 <td class="left">Expires: September 1 0, 2011</td>434 <td class="left">Expires: September 11, 2011</td> 435 435 <td class="right">J. Mogul</td> 436 436 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">March 9, 2011</td>491 <td class="right">March 10, 2011</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire on September 1 0, 2011.</p>517 <p>This Internet-Draft will expire on September 11, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 939 939 for that resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist. 940 940 </p> 941 <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,942 such as PUT, from modifying a resource that has changed since the client last retrieved it.941 <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating request 942 method, such as PUT, from modifying a resource that has changed since the client last retrieved it. 943 943 </p> 944 944 <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the 945 945 If-Match header field <em class="bcp14">MUST</em> be ignored. 946 946 </p> 947 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.947 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the request method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist. 948 948 </p> 949 949 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity-tag) is no longer a representation of … … 1015 1015 </p> 1016 1016 <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent 1017 a method (e.g., PUT) from inadvertently modifying an existing resource when the client believes that the resource does not1018 exist.1017 a request method (e.g., PUT) from inadvertently modifying an existing resource when the client believes that the resource 1018 does not exist. 1019 1019 </p> 1020 1020 <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current representation of the resource.</p> … … 1032 1032 the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 1033 1033 </p> 1034 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.1034 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the request method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations. 1035 1035 </p> 1036 1036 <p id="rfc.section.6.4.p.9">Examples:</p> -
draft-ietf-httpbis/latest/p5-range.html
r1155 r1162 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 0, 2011";361 content: "Expires September 11, 2011"; 362 362 } 363 363 @bottom-right { … … 406 406 <meta name="dct.creator" content="Reschke, J. F."> 407 407 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 408 <meta name="dct.issued" scheme="ISO8601" content="2011-03- 09">408 <meta name="dct.issued" scheme="ISO8601" content="2011-03-10"> 409 409 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 410 410 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 432 432 </tr> 433 433 <tr> 434 <td class="left">Expires: September 1 0, 2011</td>434 <td class="left">Expires: September 11, 2011</td> 435 435 <td class="right">J. Mogul</td> 436 436 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">March 9, 2011</td>491 <td class="right">March 10, 2011</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire on September 1 0, 2011.</p>517 <p>This Internet-Draft will expire on September 11, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p6-cache.html
r1155 r1162 362 362 } 363 363 @bottom-center { 364 content: "Expires September 1 0, 2011";364 content: "Expires September 11, 2011"; 365 365 } 366 366 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-03- 09">410 <meta name="dct.issued" scheme="ISO8601" content="2011-03-10"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: September 1 0, 2011</td>436 <td class="left">Expires: September 11, 2011</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">March 9, 2011</td>497 <td class="right">March 10, 2011</td> 498 498 </tr> 499 499 </tbody> … … 521 521 in progress”. 522 522 </p> 523 <p>This Internet-Draft will expire on September 1 0, 2011.</p>523 <p>This Internet-Draft will expire on September 11, 2011.</p> 524 524 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 525 525 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r1155 r1162 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 0, 2011";361 content: "Expires September 11, 2011"; 362 362 } 363 363 @bottom-right { … … 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2011-03- 09">405 <meta name="dct.issued" scheme="ISO8601" content="2011-03-10"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: September 1 0, 2011</td>436 <td class="left">Expires: September 11, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">March 9, 2011</td>489 <td class="right">March 10, 2011</td> 490 490 </tr> 491 491 </tbody> … … 513 513 in progress”. 514 514 </p> 515 <p>This Internet-Draft will expire on September 1 0, 2011.</p>515 <p>This Internet-Draft will expire on September 11, 2011.</p> 516 516 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 517 517 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.