Changeset 1715
- Timestamp:
- 04/07/12 19:54:55 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1714 r1715 1377 1377 status code (<a href="#status-code">Paragraph 3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., 1378 1378 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1379 Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), 2041380 (No Content), and <a href="p4-conditional.html#status.304" class="smpl">304(Not Modified)</a> 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. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)1379 Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 1380 (Not Modified)</a> 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. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.) 1381 1381 </p> 1382 1382 <div id="rfc.iref.t.4"></div> … … 1429 1429 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential 1430 1430 transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would 1431 have been sent in a 200 (OK)response.1431 have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. 1432 1432 </p> 1433 1433 <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only -
draft-ietf-httpbis/latest/p1-messaging.xml
r1714 r1715 1484 1484 Successful (2xx) responses to CONNECT switch to tunnel mode instead of 1485 1485 having a message body. 1486 All 1xx (Informational), 204 (No Content), and <x:ref>304 (Not Modified)</x:ref>1487 responses &MUST-NOT; include a message body.1486 All 1xx (Informational), <x:ref>204 (No Content)</x:ref>, and <x:ref>304 1487 (Not Modified)</x:ref> responses &MUST-NOT; include a message body. 1488 1488 All other responses do include a message body, although the body 1489 1489 &MAY; be of zero length. (See &status-codes; and &status-304;.) … … 1606 1606 In the case of a <x:ref>304 (Not Modified)</x:ref> response (&status-304;) 1607 1607 to a GET request, Content-Length indicates the size of the payload body (without 1608 any potential transfer-coding) that would have been sent in a 200 (OK)1608 any potential transfer-coding) that would have been sent in a <x:ref>200 (OK)</x:ref> 1609 1609 response. 1610 1610 </t> … … 4109 4109 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/> 4110 4110 <x:source href="p2-semantics.xml" basename="p2-semantics"> 4111 <x:defines>200 (OK)</x:defines> 4112 <x:defines>204 (No Content)</x:defines> 4111 4113 <x:defines>301 (Moved Permanently)</x:defines> 4112 4114 <x:defines>400 (Bad Request)</x:defines> -
draft-ietf-httpbis/latest/p2-semantics.html
r1714 r1715 1021 1021 URI. 1022 1022 </p> 1023 <p id="rfc.section.2.3.4.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 1024 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a 1025 representation that describes the result. 1026 </p> 1027 <p id="rfc.section.2.3.4.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 1028 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.13</a>). 1023 <p id="rfc.section.2.3.4.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 1024 the result. 1025 </p> 1026 <p id="rfc.section.2.3.4.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 Location header 1027 field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.13</a>). 1029 1028 </p> 1030 1029 <p id="rfc.section.2.3.4.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. … … 1037 1036 <p id="rfc.section.2.3.5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 1038 1037 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1039 that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there 1040 is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents 1041 in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful 1042 response only implies that the user agent's intent was achieved at the time of its processing by the origin server. 1043 </p> 1044 <p id="rfc.section.2.3.5.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 1045 representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) 1046 or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1038 that same target resource will result in an equivalent representation being returned 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 1039 upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent 1040 GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing 1041 by the origin server. 1042 </p> 1043 <p id="rfc.section.2.3.5.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 <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance 1044 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. 1047 1045 </p> 1048 1046 <p id="rfc.section.2.3.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). … … 1100 1098 location. 1101 1099 </p> 1102 <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been 1103 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 1100 <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes an 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. 1104 1101 </p> 1105 1102 <p id="rfc.section.2.3.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing … … 1112 1109 <div id="rfc.iref.t.1"></div> 1113 1110 <div id="rfc.iref.m.7"></div> 1114 <p id="rfc.section.2.3.7.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 either1115 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in therequest (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.1111 <p id="rfc.section.2.3.7.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 <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a Max-Forwards value of zero (0) in 1112 the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1116 1113 </p> 1117 1114 <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing … … 1704 1701 can be omitted (e.g., in the case of a response to a PUT request). 1705 1702 </p> 1706 <p id="rfc.section.4.4.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 202 (Accepted)response instead.1703 <p id="rfc.section.4.4.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 href="#status.202" class="smpl">202 (Accepted)</a> response instead. 1707 1704 </p> 1708 1705 <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource … … 1726 1723 <p id="rfc.section.4.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1727 1724 </p> 1728 <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the statuscode1729 before transformation would have been different, the 214 Transformation Applied warn-code(<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.1725 <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code 1726 (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate. 1730 1727 </p> 1731 1728 <p id="rfc.section.4.4.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. … … 2356 2353 identified by the effective request URI). The precise semantics of a representation are determined by the type of message 2357 2354 (request or response), the request method, the response status code, and the representation metadata. For example, the above 2358 semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200 2359 response to PUT, in contrast, contains either a representation that describes the successful action or a representation of 2360 the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request 2361 URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what 2362 next steps are suggested for resolving it. 2355 semantic is true for the representation in any <a href="#status.200" class="smpl">200 (OK)</a> response to GET and for the representation in any PUT request. A 200 response to PUT, in contrast, contains either a representation 2356 that describes the successful action or a representation of the target resource, with the latter indicated by a Content-Location 2357 header field with the same value as the effective request URI. Likewise, response messages with an error status code usually 2358 contain a representation that describes the error and what next steps are suggested for resolving it. 2363 2359 </p> 2364 2360 <p id="rfc.section.7.p.3">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists … … 2972 2968 </p> 2973 2969 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2974 </pre><p id="rfc.section.9.13.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, 2975 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2970 </pre><p id="rfc.section.9.13.p.3">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2976 2971 </p> 2977 2972 <p id="rfc.section.9.13.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, … … 2990 2985 </div> 2991 2986 <p id="rfc.section.9.13.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2992 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. 2987 in a <a href="#status.201" class="smpl">201 2988 (Created)</a> response, where the Location header field specifies the URI for the entire created resource. 2993 2989 </p> 2994 2990 <div class="note" id="rfc.section.9.13.p.9"> … … 3948 3944 <p id="rfc.section.C.p.4">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 4.2</a>) 3949 3945 </p> 3950 <p id="rfc.section.C.p.5">Broadened the definition of 203 (Non-Authoritative Information)to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 4.4.4</a>)3946 <p id="rfc.section.C.p.5">Broadened the definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 4.4.4</a>) 3951 3947 </p> 3952 3948 <p id="rfc.section.C.p.6">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" title="Redirection 3xx">Section 4.5</a>) … … 3956 3952 the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.5.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.5.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.5.7</a>) 3957 3953 </p> 3958 <p id="rfc.section.C.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource3959 needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient3960 was expected to repeatthis single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 4.5.5</a>)3961 </p> 3962 <p id="rfc.section.C.p.9">Define status 426 (Upgrade Required)(this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 4.6.15</a>)3954 <p id="rfc.section.C.p.8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through 3955 the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient was expected to repeat 3956 this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 4.5.5</a>) 3957 </p> 3958 <p id="rfc.section.C.p.9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 4.6.15</a>) 3963 3959 </p> 3964 3960 <p id="rfc.section.C.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) -
draft-ietf-httpbis/latest/p2-semantics.xml
r1714 r1715 665 665 </t> 666 666 <t> 667 The action performed by the POST method might not result in a 668 resource that can be identified by a URI. In this case, either 200669 (OK) or 204 (No Content) is the appropriate response status code,670 depending on whether or not the response includes a representation that671 describes the result.667 The action performed by the POST method might not result in a resource that 668 can be identified by a URI. In this case, either <x:ref>200 (OK)</x:ref> or 669 <x:ref>204 (No Content)</x:ref> is the appropriate response status 670 code, depending on whether or not the response includes a representation 671 that describes the result. 672 672 </t> 673 673 <t> 674 674 If a resource has been created on the origin server, the response 675 &SHOULD; be 201 (Created) and contain a representation which describes the676 status of the request and refers to the new resource, and a Location677 header field (see <xref target="header.location"/>).675 &SHOULD; be <x:ref>201 (Created)</x:ref> and contain a representation which 676 describes the status of the request and refers to the new resource, and a 677 Location header field (see <xref target="header.location"/>). 678 678 </t> 679 679 <t> … … 700 700 representation would suggest that a subsequent GET on that same target 701 701 resource will result in an equivalent representation being returned in 702 a 200 (OK) response. However, there is no guarantee that such a state703 change will be observable, since the target resource might be acted704 upon by other user agents in parallel, or might be subject to dynamic702 a <x:ref>200 (OK)</x:ref> response. However, there is no guarantee that 703 such a state change will be observable, since the target resource might be 704 acted upon by other user agents in parallel, or might be subject to dynamic 705 705 processing by the origin server, before any subsequent GET is received. 706 706 A successful response only implies that the user agent's intent was … … 710 710 If the target resource does not have a current representation and 711 711 the PUT successfully creates one, then the origin server &MUST; inform 712 the user agent by sending a 201 (Created) response. If the target713 resource does have a current representation and that representation is712 the user agent by sending a <x:ref>201 (Created)</x:ref> response. If the 713 target resource does have a current representation and that representation is 714 714 successfully modified in accordance with the state of the enclosed 715 representation, then either a 200 (OK) or 204 (No Content) response716 &SHOULD; be sent to indicate successful completion of the request.715 representation, then either a <x:ref>200 (OK)</x:ref> or <x:ref>204 (No Content)</x:ref> 716 response &SHOULD; be sent to indicate successful completion of the request. 717 717 </t> 718 718 <t> … … 828 828 </t> 829 829 <t> 830 A successful response &SHOULD; be 200 (OK) if the response includes an831 representation describing the status, 202 (Accepted) if the action has not832 yet been enacted, or 204 (No Content) if the action has been enacted833 but the response does not include a representation.830 A successful response &SHOULD; be <x:ref>200 (OK)</x:ref> if the response 831 includes an representation describing the status, <x:ref>202 (Accepted)</x:ref> 832 if the action has not yet been enacted, or <x:ref>204 (No Content)</x:ref> if 833 the action has been enacted but the response does not include a representation. 834 834 </t> 835 835 <t> … … 855 855 The TRACE method requests a remote, application-layer loop-back 856 856 of the request message. The final recipient of the request 857 &SHOULD; reflect the message received back to the client as the 858 message body of a 200 (OK)response. The final recipient is either the857 &SHOULD; reflect the message received back to the client as the message body 858 of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the 859 859 origin server or the first proxy to receive a Max-Forwards 860 860 value of zero (0) in the request (see <xref target="header.max-forwards"/>). … … 1349 1349 <iref primary="true" item="200 OK (status code)" x:for-anchor=""/> 1350 1350 <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/> 1351 <x:anchor-alias value="200 (OK)"/> 1351 1352 <t> 1352 1353 The request has succeeded. The payload returned with the response … … 1377 1378 <iref primary="true" item="201 Created (status code)" x:for-anchor=""/> 1378 1379 <iref primary="true" item="Status Codes" subitem="201 Created" x:for-anchor=""/> 1380 <x:anchor-alias value="201 (Created)"/> 1379 1381 <t> 1380 1382 The request has been fulfilled and has resulted in one or more new resources … … 1391 1393 The origin server &MUST; create the resource(s) before returning the 201 status 1392 1394 code. If the action cannot be carried out immediately, the server &SHOULD; 1393 respond with 202 (Accepted)response instead.1395 respond with <x:ref>202 (Accepted)</x:ref> response instead. 1394 1396 </t> 1395 1397 <t> … … 1404 1406 <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/> 1405 1407 <iref primary="true" item="Status Codes" subitem="202 Accepted" x:for-anchor=""/> 1408 <x:anchor-alias value="202 (Accepted)"/> 1406 1409 <t> 1407 1410 The request has been accepted for processing, but the processing has … … 1426 1429 <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/> 1427 1430 <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/> 1431 <x:anchor-alias value="203 (Non-Authoritative Information)"/> 1428 1432 <t> 1429 1433 The representation in the response has been transformed or otherwise … … 1434 1438 <t> 1435 1439 This status code is only appropriate when the response status code would 1436 have been 200 (OK) otherwise. When the status code before transformation1437 would have been different, the 214 Transformation Applied warn-code1438 (&header-warning;) is appropriate.1440 have been <x:ref>200 (OK)</x:ref> otherwise. When the status code before 1441 transformation would have been different, the 214 Transformation Applied 1442 warn-code (&header-warning;) is appropriate. 1439 1443 </t> 1440 1444 <t> … … 1447 1451 <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/> 1448 1452 <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/> 1453 <x:anchor-alias value="204 (No Content)"/> 1449 1454 <t> 1450 1455 The 204 (No Content) status code indicates that the server has … … 1717 1722 <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/> 1718 1723 <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/> 1724 <x:anchor-alias value="305 (Use Proxy)"/> 1719 1725 <t> 1720 1726 The 305 status code was defined in a previous version of this specification … … 2623 2629 by the effective request URI). The precise semantics of a representation 2624 2630 are determined by the type of message (request or response), the request 2625 method, the response status code, and the representation metadata. 2626 Forexample, the above semantic is true for the representation in any2627 200 (OK)response to GET and for the representation in any PUT request.2631 method, the response status code, and the representation metadata. For 2632 example, the above semantic is true for the representation in any 2633 <x:ref>200 (OK)</x:ref> response to GET and for the representation in any PUT request. 2628 2634 A 200 response to PUT, in contrast, contains either a representation 2629 2635 that describes the successful action or a representation of the target … … 3688 3694 </artwork></figure> 3689 3695 <t> 3690 For 201 (Created) responses, the Location is the URI of the new resource3691 which was created by the request. For 3xx responses, the location &SHOULD;3692 indicate the server's preferred URI for automatic redirection to the3693 re source.3696 For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the 3697 new resource which was created by the request. For 3xx responses, the 3698 location &SHOULD; indicate the server's preferred URI for automatic 3699 redirection to the resource. 3694 3700 </t> 3695 3701 <t> … … 3725 3731 <t> 3726 3732 There are circumstances in which a fragment identifier in a Location URI 3727 would not be appropriate. For instance, when it appears in a 201 Created3728 response, where the Location header field specifies the URI for the entire3729 created resource.3733 would not be appropriate. For instance, when it appears in a <x:ref>201 3734 (Created)</x:ref> response, where the Location header field specifies the 3735 URI for the entire created resource. 3730 3736 </t> 3731 3737 <x:note> … … 5410 5416 </t> 5411 5417 <t> 5412 Broadened the definition of 203 (Non-Authoritative Information) to include5413 cases of payload transformations as well.5418 Broadened the definition of <x:ref>203 (Non-Authoritative Information)</x:ref> 5419 to include cases of payload transformations as well. 5414 5420 (<xref target="status.203"/>) 5415 5421 </t> … … 5430 5436 </t> 5431 5437 <t> 5432 Deprecate 305 Use Proxy status code, because user agents did not implement it. 5433 It used to indicate that the target resource needs to be accessed through the 5434 proxy given by the Location field. The Location field gave the URI of the 5435 proxy. The recipient was expected to repeat this single request via the proxy. 5438 Deprecate <x:ref>305 (Use Proxy)</x:ref> status code, because user agents did 5439 not implement it. It used to indicate that the target resource needs to be 5440 accessed through the proxy given by the Location field. The Location field 5441 gave the URI of the proxy. The recipient was expected to repeat this single 5442 request via the proxy. 5436 5443 (<xref target="status.305"/>) 5437 5444 </t> 5438 5445 <t> 5439 Define status 426 (Upgrade Required) (this was incorporated from5440 <xref target="RFC2817"/>).5446 Define status <x:ref>426 (Upgrade Required)</x:ref> (this was incorporated 5447 from <xref target="RFC2817"/>). 5441 5448 (<xref target="status.426"/>) 5442 5449 </t> -
draft-ietf-httpbis/latest/p4-conditional.html
r1708 r1715 449 449 } 450 450 @bottom-center { 451 content: "Expires January 4, 2013";451 content: "Expires January 5, 2013"; 452 452 } 453 453 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 3">492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-04"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 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."> … … 516 516 </tr> 517 517 <tr> 518 <td class="left">Expires: January 4, 2013</td>518 <td class="left">Expires: January 5, 2013</td> 519 519 <td class="right">J. Reschke, Editor</td> 520 520 </tr> … … 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 3, 2012</td>527 <td class="right">July 4, 2012</td> 528 528 </tr> 529 529 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on January 4, 2013.</p>557 <p>This Internet-Draft will expire on January 5, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 692 692 </p> 693 693 <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such 694 that a change would be observable in the payload body of a 200response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,694 that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., 695 695 Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate 696 696 the stored responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same … … 1050 1050 </p> 1051 1051 <ol> 1052 <li>If the request would normally result in anything other than a 200 (OK) status code, or if the passed If-Modified-Since date 1053 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 1054 invalid. 1052 <li>If the request would normally result in anything other than a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> status code, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date 1053 which is later than the server's current time is invalid. 1055 1054 </li> 1056 1055 <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for … … 1107 1106 <div id="rfc.iref.s.2"></div> 1108 1107 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.304" href="#status.304">304 Not Modified</a></h2> 1109 <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a 200 (OK) response 1110 if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server to 1111 transfer a representation of the target resource because the client's request indicates that it already has a valid representation, 1108 <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server 1109 to transfer a representation of the target resource because the client's request indicates that it already has a valid representation, 1112 1110 as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation 1113 1111 as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields. -
draft-ietf-httpbis/latest/p4-conditional.xml
r1708 r1715 271 271 changed to a new, previously unused or guaranteed unique, value whenever 272 272 a change occurs to the representation data such that a change would be 273 observable in the payload body of a 200 response to GET. A strong274 validator &MAY; be changed for other reasons, such as when a semantically273 observable in the payload body of a <x:ref>200 (OK)</x:ref> response to GET. 274 A strong validator &MAY; be changed for other reasons, such as when a semantically 275 275 significant part of the representation metadata is changed (e.g., 276 276 Content-Type), but it is in the best interests of the origin server to only … … 883 883 <list style="numbers"> 884 884 <t>If the request would normally result in anything other than a 885 200 (OK)status code, or if the passed If-Modified-Since date is885 <x:ref>200 (OK)</x:ref> status code, or if the passed If-Modified-Since date is 886 886 invalid, the response is exactly the same as for a normal GET. 887 887 A date which is later than the server's current time is … … 994 994 <t> 995 995 The 304 status code indicates that a conditional GET request has been 996 received and would have resulted in a 200 (OK)response if it were not996 received and would have resulted in a <x:ref>200 (OK)</x:ref> response if it were not 997 997 for the fact that the condition has evaluated to false. In other words, 998 998 there is no need for the server to transfer a representation of the … … 1193 1193 </front> 1194 1194 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/> 1195 <x:source href="p2-semantics.xml" basename="p2-semantics"/> 1195 <x:source href="p2-semantics.xml" basename="p2-semantics"> 1196 <x:defines>200 (OK)</x:defines> 1197 </x:source> 1196 1198 </reference> 1197 1199 -
draft-ietf-httpbis/latest/p5-range.html
r1708 r1715 449 449 } 450 450 @bottom-center { 451 content: "Expires January 4, 2013";451 content: "Expires January 5, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 3">494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-04"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 496 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 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 requests and the rules for constructing and combining responses to those requests."> … … 518 518 </tr> 519 519 <tr> 520 <td class="left">Expires: January 4, 2013</td>520 <td class="left">Expires: January 5, 2013</td> 521 521 <td class="right">J. Reschke, Editor</td> 522 522 </tr> … … 527 527 <tr> 528 528 <td class="left"></td> 529 <td class="right">July 3, 2012</td>529 <td class="right">July 4, 2012</td> 530 530 </tr> 531 531 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on January 4, 2013.</p>557 <p>This Internet-Draft will expire on January 5, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 742 742 </li> 743 743 <li>Date</li> 744 <li>Cache-Control, ETag, Expires, Content-Location and/or Vary, if the header field would have been sent in a 200 response to 745 the same request 746 </li> 747 </ul> 748 <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an If-Range header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request. 744 <li>Cache-Control, ETag, Expires, Content-Location and/or Vary, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request 745 </li> 746 </ul> 747 <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an If-Range header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request. 749 748 </p> 750 749 <p id="rfc.section.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses. … … 765 764 </pre><div class="note" id="rfc.section.3.2.p.4"> 766 765 <p> <b>Note:</b> Clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested 767 Range Not Satisfiable)</a> response instead of a 200 (OK) response for an unsatisfiable Range header field, since not all servers implement this header 768 field. 766 Range Not Satisfiable)</a> response instead of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable Range header field, since not all servers implement this header field. 769 767 </p> 770 768 </div> … … 799 797 defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 800 798 </p> 801 <p id="rfc.section.4.2.p.2">When a client receives an incomplete 200 (OK)or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses799 <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses 802 800 with the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator, 803 801 then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses. 804 802 </p> 805 <p id="rfc.section.4.2.p.3">If the new response is an incomplete 200 (OK) response, then the header fields of that new response are used for any combined806 response and replace those of the matchingstored responses.807 </p> 808 <p id="rfc.section.4.2.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a 200 (OK), then the combined response header fields consist809 of the most recent 200 response's header fields. If all of the matching stored responses are 206 responses, then the stored810 response with the most header fields is used as the source of header fieldsfor the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding803 <p id="rfc.section.4.2.p.3">If the new response is an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that new response are used for any combined response and replace those of the matching 804 stored responses. 805 </p> 806 <p id="rfc.section.4.2.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching 807 stored responses are 206 responses, then the stored response with the most header fields is used as the source of header fields 808 for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding 811 809 header fields in the stored response. 812 810 </p> 813 811 <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected 814 responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete 200 (OK) response with a Content-Length header field that reflects the complete length. Otherwise, 815 the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists 812 responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a Content-Length header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists 816 813 of a discontinuous range of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple 206 responses with one continuous range each. 817 814 </p> … … 887 884 </ul> 888 885 <p id="rfc.section.5.2.p.10">If the server ignores a byte-range-spec (for example if it is syntactically invalid, or if it might be seen as a denial-of-service 889 attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing 890 the full representation). 886 attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing the full representation). 891 887 </p> 892 888 <div id="rfc.iref.i.1"></div> … … 911 907 </p> 912 908 <p id="rfc.section.5.3.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target 913 resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a 200 (OK)response.909 resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. 914 910 </p> 915 911 <div id="rfc.iref.r.1"></div> … … 987 983 <ul> 988 984 <li>The presence of a Range header field in an unconditional GET modifies what is returned if the GET is otherwise successful. 989 In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of 200 (OK).985 In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>. 990 986 </li> 991 987 <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match, -
draft-ietf-httpbis/latest/p5-range.xml
r1708 r1715 335 335 <t> 336 336 Cache-Control, ETag, Expires, Content-Location and/or Vary, if 337 the header field would have been sent in a 200response to the337 the header field would have been sent in a <x:ref>200 (OK)</x:ref> response to the 338 338 same request 339 339 </t> … … 344 344 &SHOULD-NOT; include other representation header fields. Otherwise, the response 345 345 &MUST; include all of the representation header fields that would have been returned 346 with a 200 (OK)response to the same request.346 with a <x:ref>200 (OK)</x:ref> response to the same request. 347 347 </t> 348 348 <t> … … 380 380 <t> 381 381 &Note; Clients cannot depend on servers to send a <x:ref>416 (Requested 382 Range Not Satisfiable)</x:ref> response instead of a 200 (OK) response for383 an unsatisfiable Range header field, since not all servers382 Range Not Satisfiable)</x:ref> response instead of a <x:ref>200 (OK)</x:ref> 383 response for an unsatisfiable Range header field, since not all servers 384 384 implement this header field. 385 385 </t> … … 444 444 </t> 445 445 <t> 446 When a client receives an incomplete 200 (OK)or <x:ref>206 (Partial Content)</x:ref>446 When a client receives an incomplete <x:ref>200 (OK)</x:ref> or <x:ref>206 (Partial Content)</x:ref> 447 447 response and already has one or more stored responses for the same method 448 448 and effective request URI, all of the stored responses with the same … … 453 453 </t> 454 454 <t> 455 If the new response is an incomplete 200 (OK)response, then the header455 If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then the header 456 456 fields of that new response are used for any combined response and replace 457 457 those of the matching stored responses. … … 459 459 <t> 460 460 If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one 461 of the matching stored responses is a 200 (OK), then the combined response461 of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response 462 462 header fields consist of the most recent 200 response's header fields. 463 463 If all of the matching stored responses are 206 responses, then the … … 472 472 content ranges in the new response and each of the selected responses. 473 473 If the union consists of the entire range of the representation, then the 474 combined response &MUST; be recorded as a complete 200 (OK)response474 combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref> response 475 475 with a Content-Length header field that reflects the complete length. 476 476 Otherwise, the combined response(s) &MUST; include a Content-Range … … 626 626 syntactically invalid, or if it might be seen as a denial-of-service 627 627 attack), the server &SHOULD; treat the request as if the invalid Range 628 header field did not exist. (Normally, this means return a 200628 header field did not exist. (Normally, this means return a <x:ref>200 (OK)</x:ref> 629 629 response containing the full representation). 630 630 </t> … … 681 681 the server &SHOULD; send the specified sub-range of the representation 682 682 using a <x:ref>206 (Partial Content)</x:ref> response. If the validator does not match, 683 then the server &SHOULD; send the entire representation using a 200 (OK)683 then the server &SHOULD; send the entire representation using a <x:ref>200 (OK)</x:ref> 684 684 response. 685 685 </t> … … 833 833 what is returned if the GET is otherwise successful. In other 834 834 words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref> 835 instead of 200 (OK).</t>835 instead of <x:ref>200 (OK)</x:ref>.</t> 836 836 837 837 <t>The presence of a Range header field in a conditional GET (a request … … 1020 1020 </front> 1021 1021 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/> 1022 <x:source href="p2-semantics.xml" basename="p2-semantics"/> 1022 <x:source href="p2-semantics.xml" basename="p2-semantics"> 1023 <x:defines>200 (OK)</x:defines> 1024 </x:source> 1023 1025 </reference> 1024 1026 -
draft-ietf-httpbis/latest/p6-cache.html
r1713 r1715 832 832 </p> 833 833 <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common 834 form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of835 the resource identified by the request target. However, it is also possible to cachenegative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable834 form of cache entry is a successful result of a retrieval request: i.e., a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing a representation of the resource identified by the request target. However, it is also possible to cache 835 negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable 836 836 for use as a cache key. 837 837 </p> … … 876 876 time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses. 877 877 </p> 878 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire 879 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does 878 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does 880 879 not understand the range units used in those fields. 881 880 </p> … … 1095 1094 </ul> 1096 1095 <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a> <a id="freshening.responses" href="#freshening.responses">Freshening Responses with 304 Not Modified</a></h3> 1097 <p id="rfc.section.2.4.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored 200 (OK) responses for the same cache key, the cache needs to identify which of 1098 the stored responses are updated by this new response and then update the stored response(s) with the new information provided 1099 in the 304 response. 1096 <p id="rfc.section.2.4.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response 1097 and then update the stored response(s) with the new information provided in the 304 response. 1100 1098 </p> 1101 1099 <ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r1713 r1715 432 432 HTTP responses corresponding to prior requests that used the same key. 433 433 The most common form of cache entry is a successful result of a retrieval 434 request: i.e., a 200 (OK) response containing a representation of the435 resource identified by the request target. However, it is also possible434 request: i.e., a <x:ref>200 (OK)</x:ref> response containing a representation 435 of the resource identified by the request target. However, it is also possible 436 436 to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results 437 437 (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than … … 504 504 A response message is considered complete when all of the octets 505 505 indicated by the message framing (&messaging;) are received 506 prior to the connection being closed. 507 If the request is GET, the response status is 200 (OK), and the entire506 prior to the connection being closed. If the request is GET, the response 507 status is <x:ref>200 (OK)</x:ref>, and the entire 508 508 response header block has been received, a cache &MAY; store an incomplete 509 509 response message body if the cache entry is recorded as incomplete. 510 510 Likewise, a <x:ref>206 (Partial Content)</x:ref> response &MAY; be stored as if it were 511 an incomplete 200 (OK)cache entry. However, a cache &MUST-NOT; store511 an incomplete <x:ref>200 (OK)</x:ref> cache entry. However, a cache &MUST-NOT; store 512 512 incomplete or partial content responses if it does not support the Range 513 513 and Content-Range header fields or if it does not understand the … … 929 929 <t> 930 930 When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and already has one 931 or more stored 200 (OK)responses for the same cache key, the cache needs931 or more stored <x:ref>200 (OK)</x:ref> responses for the same cache key, the cache needs 932 932 to identify which of the stored responses are updated by this new response 933 933 and then update the stored response(s) with the new information provided in … … 2288 2288 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" /> 2289 2289 <x:source basename="p2-semantics" href="p2-semantics.xml"> 2290 <x:defines>200 (OK)</x:defines> 2290 2291 <x:defines>404 (Not Found)</x:defines> 2291 2292 <x:defines>504 (Gateway Timeout)</x:defines>
Note: See TracChangeset
for help on using the changeset viewer.