Changeset 928 for draft-ietf-httpbis/latest
- Timestamp:
- 24/07/10 14:06:46 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 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> -
draft-ietf-httpbis/latest/p4-conditional.html
r923 r928 873 873 <p id="rfc.section.5.p.7">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since 874 874 or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header 875 field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in876 the request.875 field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields 876 in the request. 877 877 </p> 878 878 <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags … … 938 938 such as PUT, from modifying a resource that has changed since the client last retrieved it. 939 939 </p> 940 <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 , then the If-Match941 header <em class="bcp14">MUST</em> be ignored.940 <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 941 If-Match header <em class="bcp14">MUST</em> be ignored. 942 942 </p> 943 943 <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. … … 970 970 </p> 971 971 <ol> 972 <li>If the request would normally result in anything other than a 200 (OK) status, or if the passed If-Modified-Since date is 973 invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is invalid. 972 <li>If the request would normally result in anything other than a 200 (OK) status code, or if the passed If-Modified-Since date 973 is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is 974 invalid. 974 975 </li> 975 976 <li>If the representation has been modified since the If-Modified-Since date, the response is exactly the same as for a normal … … 1020 1021 for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied 1021 1022 in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the representations 1022 that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed).1023 that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed) status code. 1023 1024 </p> 1024 1025 <p id="rfc.section.6.4.p.6">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response. 1025 1026 </p> 1026 <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status , then the1027 If-None-Match header <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.)1027 <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then 1028 the If-None-Match header <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.) 1028 1029 </p> 1029 1030 <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. … … 1052 1053 </pre><p id="rfc.section.6.5.p.4">An example of the field is:</p> 1053 1054 <div id="rfc.figure.u.16"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1054 </pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status ,1055 the If-Unmodified-Since header <em class="bcp14">SHOULD</em> be ignored.1055 </pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status 1056 code, the If-Unmodified-Since header <em class="bcp14">SHOULD</em> be ignored. 1056 1057 </p> 1057 1058 <p id="rfc.section.6.5.p.7">If the specified date is invalid, the header is ignored.</p> -
draft-ietf-httpbis/latest/p5-range.html
r923 r928 848 848 <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current 849 849 length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set 850 is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content)containing the satisfiable ranges of the representation.850 is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a 416 (Requested range not satisfiable) status code. Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a 206 (Partial Content) status code containing the satisfiable ranges of the representation. 851 851 </p> 852 852 <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a representation of length 10000): </p> -
draft-ietf-httpbis/latest/p6-cache.html
r923 r928 1122 1122 <li>The only-if-cached request directive indicates that the client only wishes to return a stored response. If it receives this 1123 1123 directive, a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 1124 (Gateway Timeout) status . If a group of caches is being operated as a unified system with good internal connectivity, such1125 a request <em class="bcp14">MAY</em> be forwarded within that group of caches.1124 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, 1125 such a request <em class="bcp14">MAY</em> be forwarded within that group of caches. 1126 1126 </li> 1127 1127 </ul>
Note: See TracChangeset
for help on using the changeset viewer.