Changeset 2052 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 16/12/12 03:46:23 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2051 r2052 1257 1257 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="method.overview" href="#method.overview">Overview</a></h2> 1258 1258 <p id="rfc.section.4.1.p.1">The request method token is the primary source of request semantics; it indicates the purpose for which the client has made 1259 this request and what is expected by the client as a successful result. The request semantics <em class="bcp14">MAY</em> be further specialized by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section 5</a>) if those additional semantics do not conflict with the method. 1259 this request and what is expected by the client as a successful result. The request semantics might be further specialized 1260 by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section 5</a>) if those additional semantics do not conflict with the method. 1260 1261 </p> 1261 1262 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#method.overview" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a> … … 1266 1267 </p> 1267 1268 <p id="rfc.section.4.1.p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide 1268 for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method <em class="bcp14">MUST</em> have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are1269 implemented or allowed.1269 for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource 1270 determines for itself whether those semantics are implemented or allowed. 1270 1271 </p> 1271 1272 <p id="rfc.section.4.1.p.5">This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table. … … 1326 1327 </table> 1327 1328 </div> 1328 <p id="rfc.section.4.1.p.6"> The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. When implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section 4.3</a>.1329 </p> 1330 <p id="rfc.section.4.1.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and ought to be registered within1331 t he HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 8.1</a>.1329 <p id="rfc.section.4.1.p.6">All general-purpose servers <em class="bcp14">MUST</em> support the methods GET and HEAD. All other methods are <em class="bcp14">OPTIONAL</em>; when implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section 4.3</a>. 1330 </p> 1331 <p id="rfc.section.4.1.p.7">Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought 1332 to be registered within the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 8.1</a>. 1332 1333 </p> 1333 1334 <p id="rfc.section.4.1.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 7.4.1</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or … … 1349 1350 the Web will often have the side-effect of charging an advertising account. 1350 1351 </p> 1351 <p id="rfc.section.4.2.1.p.3"> The GET, HEAD, OPTIONS, and TRACE requestmethods are defined to be safe.</p>1352 <p id="rfc.section.4.2.1.p.3">Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.</p> 1352 1353 <p id="rfc.section.4.2.1.p.4">The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache 1353 1354 performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply … … 1366 1367 <div id="rfc.iref.i.1"></div> 1367 1368 <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 1368 <p id="rfc.section.4.2.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request1369 methods are idempotent.1369 <p id="rfc.section.4.2.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. Of the request methods defined 1370 by this specification, the PUT, DELETE, and safe request methods are idempotent. 1370 1371 </p> 1371 1372 <p id="rfc.section.4.2.2.p.2">Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free … … 1390 1391 <div id="rfc.iref.g.16"></div> 1391 1392 <p id="rfc.section.4.3.1.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1392 <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation1393 in the response and not the source textof the process, unless that text happens to be the output of the process.1393 <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, the produced data will be sent as the representation, not the source text 1394 of the process, unless that text happens to be the output of the process. 1394 1395 </p> 1395 1396 <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional … … 1409 1410 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 1410 1411 <div id="rfc.iref.h.1"></div> 1411 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> returna message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1412 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1412 1413 representation implied by the request without transferring the representation data. This method is often used for testing 1413 1414 hypertext links for validity, accessibility, and recent modification. … … 1421 1422 <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a> <a id="POST" href="#POST">POST</a></h3> 1422 1423 <p id="rfc.section.4.3.3.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed 1423 by the target resource. POST is designed to allow a uniform method to cover the following functions:1424 by the target resource. For example, POST is frequently used for the following functions (among others): 1424 1425 </p> 1425 1426 <ul> … … 1429 1430 <li>Extending a database through an append operation.</li> 1430 1431 </ul> 1431 <p id="rfc.section.4.3.3.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request1432 URI.1432 <p id="rfc.section.4.3.3.p.2">The actual function performed by the POST method is determined by the origin server and is usually dependent on the effective 1433 request URI. 1433 1434 </p> 1434 1435 <p id="rfc.section.4.3.3.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes 1435 1436 the result. 1436 1437 </p> 1437 <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.2</a>).1438 <p id="rfc.section.4.3.3.p.4">If one or more resources has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a>, contain a representation which describes the status of the request and refers to the new resource(s), and include a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.2</a>). 1438 1439 </p> 1439 1440 <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 3.1.4.2</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD (not POST) requests. … … 1445 1446 <p id="rfc.section.4.3.4.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 1446 1447 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1447 that same target resource will result in an equivalent representation being returnedin a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted1448 that same target resource will result in an equivalent representation being sent in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted 1448 1449 upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent 1449 1450 GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing … … 1453 1454 with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1454 1455 </p> 1455 <p id="rfc.section.4.3.4.p.3"> Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not savedas part of the resource state).1456 <p id="rfc.section.4.3.4.p.3">An origin server <em class="bcp14">SHOULD</em> ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state). 1456 1457 </p> 1457 1458 <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot … … 1506 1507 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> 1507 1508 <div id="rfc.iref.d.2"></div> 1508 <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1509 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1510 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible 1511 location. 1512 </p> 1513 <p id="rfc.section.4.3.5.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation. 1514 </p> 1515 <p id="rfc.section.4.3.5.p.3">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause 1509 <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the target resource and its current representations 1510 or implementation. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI 1511 mapping of the origin server, rather than an expectation that the information be deleted. The representations might or might 1512 not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the 1513 nature of the resource and its implementation by the origin server (which are beyond the scope of this specification). 1514 </p> 1515 <p id="rfc.section.4.3.5.p.2">Relatively few resources allow the DELETE method — its primary use is for remote authoring environments, where the user has 1516 some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified 1517 via the Location header field after a <a href="#status.201" class="smpl">201 (Created)</a> response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent 1518 implementations that implement an authoring function, such as revision control clients using HTTP for remote operations, might 1519 use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository. 1520 </p> 1521 <p id="rfc.section.4.3.5.p.3">If a DELETE method is successfully applied, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.202" class="smpl">202 (Accepted)</a> status code if the action seems okay but has not yet been enacted, or a <a href="#status.204" class="smpl">204 (No Content)</a> status code if the action has been enacted and no further information is to be supplied, or a <a href="#status.200" class="smpl">200 (OK)</a> status code if the action has been enacted and the response message includes a representation describing the status. 1522 </p> 1523 <p id="rfc.section.4.3.5.p.4">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause 1516 1524 some existing implementations to reject the request. 1517 1525 </p> 1518 <p id="rfc.section.4.3.5.p. 4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses1526 <p id="rfc.section.4.3.5.p.5">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1519 1527 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1520 1528 </p> 1521 1529 <div id="rfc.iref.c.9"></div> 1522 1530 <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3> 1523 <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict 1524 its behavior to blind forwarding of packets until the connection is closed. 1525 </p> 1526 <p id="rfc.section.4.3.6.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 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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. 1531 <p id="rfc.section.4.3.6.p.1">The CONNECT method is only applicable as a request to a proxy. A CONNECT requests that the recipient establish a tunnel to 1532 the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind 1533 forwarding of packets, in both directions, until the connection is closed. 1534 </p> 1535 <p id="rfc.section.4.3.6.p.2">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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. 1527 1536 For example, 1528 1537 </p> … … 1530 1539 Host: server.example.com:80 1531 1540 1532 </pre><p id="rfc.section.4.3.6.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has 1533 switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately 1534 after the blank line that concludes the successful response's header block. 1541 </pre><p id="rfc.section.4.3.6.p.4">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another 1542 proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the sender (and any inbound proxies) will switch to tunnel mode immediately after 1543 the blank line that concludes the successful response's header block; data received after that blank line is from the server 1544 identified by the request-target. 1535 1545 </p> 1536 1546 <p id="rfc.section.4.3.6.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. … … 1539 1549 governed by HTTP. 1540 1550 </p> 1541 <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel :</p>1551 <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p> 1542 1552 <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1543 1553 Host: server.example.com:80 … … 1547 1557 some existing implementations to reject the request. 1548 1558 </p> 1549 <p id="rfc.section.4.3.6.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded 1550 if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 1551 </p> 1552 <p id="rfc.section.4.3.6.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, 1553 the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority. 1554 </p> 1555 <p id="rfc.section.4.3.6.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1556 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1557 peer undelivered, that data will be discarded. 1558 </p> 1559 <p id="rfc.section.4.3.6.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1559 <p id="rfc.section.4.3.6.p.10">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side 1560 will first be sent to the other side and then the intermediary will close both connections. If there is outstanding data left 1561 undelivered, that data will be discarded. 1562 </p> 1563 <p id="rfc.section.4.3.6.p.11">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1560 1564 </p> 1561 1565 <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> … … 1683 1687 <p id="rfc.section.5.1.2.1.p.4">Requirements for HTTP/1.1 origin servers: </p> 1684 1688 <ul> 1685 <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> 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.1689 <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request. 1686 1690 </li> 1687 1691 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility … … 2382 2386 <div id="rfc.iref.72"></div> 2383 2387 <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> 2384 <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload returned withthe response is dependent on the method used in the request, for example: </p>2388 <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload sent in the response is dependent on the method used in the request, for example: </p> 2385 2389 <dl> 2386 2390 <dt>GET</dt> … … 2402 2406 (e.g., in the case of a response to a PUT request). 2403 2407 </p> 2404 <p id="rfc.section.6.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.2408 <p id="rfc.section.6.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before sending the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead. 2405 2409 </p> 2406 2410 <p id="rfc.section.6.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by … … 2415 2419 <p id="rfc.section.6.3.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process 2416 2420 (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the 2417 server persist until the process is completed. The representation returnedwith this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the2421 server persist until the process is completed. The representation sent with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the 2418 2422 user can expect the request to be fulfilled. 2419 2423 </p> … … 2429 2433 <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 2430 2434 <p id="rfc.section.6.3.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional 2431 content to returnin the response payload body. Metadata in the response header fields refer to the target resource and its2435 content to send in the response payload body. Metadata in the response header fields refer to the target resource and its 2432 2436 current representation after the requested action. 2433 2437 </p> … … 2514 2518 <div id="rfc.iref.73"></div> 2515 2519 <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> 2516 <p id="rfc.section.6.4.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective2517 request URI to one or more of the new references returnedby the server, where possible.2520 <p id="rfc.section.6.4.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the enclosed URIs. Clients with link editing capabilities ought to automatically re-link references to the effective 2521 request URI to one or more of the new references sent by the server, where possible. 2518 2522 </p> 2519 2523 <p id="rfc.section.6.4.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 301 responses. … … 2617 2621 </p> 2618 2622 <div class="note" id="rfc.section.6.5.6.p.3"> 2619 <p> <b>Note:</b> HTTP/1.1 servers are allowed to returnresponses which are not acceptable according to the accept header fields sent in the2623 <p> <b>Note:</b> HTTP/1.1 servers are allowed to send responses which are not acceptable according to the accept header fields sent in the 2620 2624 request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the 2621 2625 header fields of an incoming response to determine if it is acceptable. … … 2737 2741 </p> 2738 2742 <div class="note" id="rfc.section.6.6.5.p.2"> 2739 <p> <b>Note</b> to implementers: some deployed proxies are known to return<a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server2743 <p> <b>Note</b> to implementers: some deployed proxies are known to send <a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server 2740 2744 Error)</a> when DNS lookups time out. 2741 2745 </p>
Note: See TracChangeset
for help on using the changeset viewer.