Changeset 928 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 24/07/10 14:06:46 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r923 r928 875 875 </p> 876 876 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2> 877 <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response.</p>877 <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status-Line of an HTTP response.</p> 878 878 <p id="rfc.section.4.1.p.2">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 879 879 </p> … … 917 917 at the Effective Request URI. 918 918 </li> 919 <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation919 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation 920 920 of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 921 921 </li> … … 1033 1033 </p> 1034 1034 <p id="rfc.section.7.5.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 1035 200 (OK) or 204 (No Content) is the appropriate response status , depending on whether or not the response includes a representation1036 that describes the result.1035 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a 1036 representation that describes the result. 1037 1037 </p> 1038 1038 <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and … … 1057 1057 <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1058 1058 </p> 1059 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request is a success status. Responses to the PUT method are not cacheable.1059 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable. 1060 1060 </p> 1061 1061 <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request … … 1197 1197 <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body. 1198 1198 The resource metadata and representation metadata in the response message's header fields refer to the requested resource 1199 and its current representation, respectively, after the requested action. For example, if a 204 status is received in response1200 to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation1201 th at was successfully PUT to the requested resource.1199 and its current representation, respectively, after the requested action. For example, if a 204 status code is received in 1200 response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for 1201 the representation that was successfully PUT to the requested resource. 1202 1202 </p> 1203 1203 <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input … … 1288 1288 resource. 1289 1289 </p> 1290 <p id="rfc.section.8.3.4.p.2">The 303 status is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect1291 t he user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form1292 that can be separately identified, bookmarked, and cached independent of the original request.1290 <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action 1291 to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response 1292 in a form that can be separately identified, bookmarked, and cached independent of the original request. 1293 1293 </p> 1294 1294 <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be … … 1309 1309 <div id="rfc.iref.s.16"></div> 1310 1310 <h3 id="rfc.section.8.3.6"><a href="#rfc.section.8.3.6">8.3.6</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3> 1311 <p id="rfc.section.8.3.6.p.1">The 305 status was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix A</a>), and is now deprecated.1311 <p id="rfc.section.8.3.6.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix A</a>), and is now deprecated. 1312 1312 </p> 1313 1313 <div id="rfc.iref.40"></div> … … 1321 1321 </p> 1322 1322 <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand 1323 the 307 status . Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.1323 the 307 status code. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI. 1324 1324 </p> 1325 1325 <p id="rfc.section.8.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which … … 1551 1551 *<a href="#header.expect" class="smpl">expect-params</a> ] 1552 1552 <a href="#header.expect" class="smpl">expect-params</a> = ";" <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ] 1553 </pre><p id="rfc.section.9.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status . The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with1554 the request, some other 4xx status.1553 </pre><p id="rfc.section.9.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status code. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code if any of the expectations cannot be met or, if there are other problems 1554 with the request, some other 4xx status code. 1555 1555 </p> 1556 1556 <p id="rfc.section.9.2.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing 1557 an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status .1557 an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. 1558 1558 </p> 1559 1559 <p id="rfc.section.9.2.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive 1560 1560 for quoted-string expectation-extensions. 1561 1561 </p> 1562 <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect1563 request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.1562 <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the 1563 Expect request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 1564 1564 </p> 1565 1565 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p> 1566 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status .1566 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 1567 1567 </p> 1568 1568 <div id="rfc.iref.f.1"></div>
Note: See TracChangeset
for help on using the changeset viewer.