Changeset 1735
- Timestamp:
- 06/07/12 14:48:51 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 11 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p0-introduction.html
r1725 r1735 393 393 } 394 394 @bottom-center { 395 content: "Expires January 6, 2013";395 content: "Expires January 7, 2013"; 396 396 } 397 397 @bottom-right { … … 426 426 <meta name="dct.creator" content="Reschke, J. F."> 427 427 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest"> 428 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 5">428 <meta name="dct.issued" scheme="ISO8601" content="2012-07-06"> 429 429 <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> 430 430 <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> … … 446 446 </tr> 447 447 <tr> 448 <td class="left">Expires: January 6, 2013</td>448 <td class="left">Expires: January 7, 2013</td> 449 449 <td class="right">W3C</td> 450 450 </tr> … … 467 467 <tr> 468 468 <td class="left"></td> 469 <td class="right">July 5, 2012</td>469 <td class="right">July 6, 2012</td> 470 470 </tr> 471 471 </tbody> … … 491 491 in progress”. 492 492 </p> 493 <p>This Internet-Draft will expire on January 6, 2013.</p>493 <p>This Internet-Draft will expire on January 7, 2013.</p> 494 494 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 495 495 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p1-messaging.html
r1734 r1735 1376 1376 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 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 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 1379 (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, Payload and Content Negotiation">[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>.) 1378 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, 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, Payload and Content Negotiation">[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>.) 1380 1379 </p> 1381 1380 <div id="rfc.iref.t.4"></div> … … 1445 1444 <ol> 1446 1445 <li> 1447 <p>Any response to a HEAD request and any response with a status code of 100-199, 204, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> is always terminated by the first empty line after the header fields, regardless of the header fields present in the message,1448 and thus cannot contain a message body.1446 <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present 1447 in the message, and thus cannot contain a message body. 1449 1448 </p> 1450 1449 </li> … … 1971 1970 <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1972 1971 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1973 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 1974 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request. 1972 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request. 1975 1973 </p> 1976 1974 <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. -
draft-ietf-httpbis/latest/p1-messaging.xml
r1734 r1735 1484 1484 <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of 1485 1485 having a message body. 1486 All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and <x:ref>3041487 (Not Modified)</x:ref> responses &MUST-NOT; include a message body.1486 All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and 1487 <x:ref>304 (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;.) … … 1643 1643 <list style="numbers"> 1644 1644 <x:lt><t> 1645 Any response to a HEAD request and any response with a status 1646 code of 100-199, 204, or <x:ref>304 (Not Modified)</x:ref> is always 1645 Any response to a HEAD request and any response with a 1646 <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, or 1647 <x:ref>304 (Not Modified)</x:ref> status code is always 1647 1648 terminated by the first empty line after the header fields, regardless of 1648 1649 the header fields present in the message, and thus cannot contain a … … 2662 2663 to the order in which requests are made on the same connection. 2663 2664 More than one response message per request only occurs when one or more 2664 informational responses ( 1xx, see &status-1xx;) precede a final response2665 informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a final response 2665 2666 to the same request. 2666 2667 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1734 r1735 966 966 with that resource. 967 967 </p> 968 <p id="rfc.section.2.3.1.p.6">A 200response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,968 <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., 969 969 Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 970 970 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". … … 1801 1801 <p> <b>Note:</b> In HTTP/1.0, only the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="#status.302" class="smpl">302 (Found)</a> were defined for the first type of redirect, and the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to 1802 1802 retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code <a href="#status.303" class="smpl">303 (See Other)</a> (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added 1803 yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification 1804 makes that behavior conformant in case the original request was POST. 1803 yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>, therefore this specification makes that behavior conformant in case the original request was POST. 1805 1804 </p> 1806 1805 </div> … … 2084 2083 </p> 2085 2084 <div class="note" id="rfc.section.4.7.5.p.2"> 2086 <p> <b>Note</b> to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. 2085 <p> <b>Note</b> to implementors: some deployed proxies are known to return <a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server 2086 Error)</a> when DNS lookups time out. 2087 2087 </p> 2088 2088 </div> … … 2391 2391 (Non-Authoritative Information)</a> and the request method was GET, the response payload is a representation of the target resource. 2392 2392 </li> 2393 <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, 206 (Partial Content, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.2393 <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource. 2394 2394 </li> 2395 2395 <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload … … 2407 2407 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2> 2408 2408 <p id="rfc.section.7.2.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message 2409 body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request 2410 with the same effective request URI. 2409 body is present, about the representation that would have been transferred in a <a href="#status.200" class="smpl">200 (OK)</a> response to a simultaneous GET request with the same effective request URI. 2411 2410 </p> 2412 2411 <p id="rfc.section.7.2.p.2">The following header fields are defined as representation metadata:</p> … … 2850 2849 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 2851 2850 <p id="rfc.section.9.8.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 2852 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response 2853 would contain the same representation that is enclosed as payload in this message. 2851 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message. 2854 2852 </p> 2855 2853 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> … … 2870 2868 indicates that this representation contains a report on the action's status and the same report is available (for future access 2871 2869 with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as 2872 the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt 2873 in the future. 2870 the payload of the <a href="#status.200" class="smpl">200 (OK)</a> response; the Content-Location value provides an identifier for retrieving a copy of that same receipt in the future. 2874 2871 </p> 2875 2872 <p id="rfc.section.9.8.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed … … 2984 2981 </p> 2985 2982 <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> 2986 </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 <a href="#status.3xx" class="smpl">3xx </a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.2983 </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 <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2987 2984 </p> 2988 2985 <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, … … 3970 3967 <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>) 3971 3968 </p> 3972 <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" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 4.5</a>)3969 <p id="rfc.section.C.p.6">Status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a>: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 4.5</a>) 3973 3970 </p> 3974 3971 <p id="rfc.section.C.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 3975 3972 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 3976 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>)3973 the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (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>) 3977 3974 </p> 3978 3975 <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 -
draft-ietf-httpbis/latest/p2-semantics.xml
r1734 r1735 542 542 </t> 543 543 <t> 544 A 200 response &SHOULD; include any header fields that indicate545 optional features implemented by the server and applicable to that544 A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that 545 indicate optional features implemented by the server and applicable to that 546 546 resource (e.g., Allow), possibly including extensions not defined by 547 547 this specification. The response body, if any, &SHOULD; also include … … 1587 1587 <x:ref>307 (Temporary Redirect)</x:ref>, for which the backwards 1588 1588 compatibility problems did not apply (<xref target="RFC2616" x:fmt="," x:sec="10.3.8"/>). 1589 Over 10 years later, most user agents still do method rewriting for 1590 status codes 301 and 302, therefore this specification makes that behavior1589 Over 10 years later, most user agents still do method rewriting for status codes 1590 <x:ref>301</x:ref> and <x:ref>302</x:ref>, therefore this specification makes that behavior 1591 1591 conformant in case the original request was POST. 1592 1592 </t> … … 1650 1650 <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/> 1651 1651 <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/> 1652 <x:anchor-alias value="301"/> 1652 1653 <x:anchor-alias value="301 (Moved Permanently)"/> 1653 1654 <t> … … 1680 1681 <iref primary="true" item="302 Found (status code)" x:for-anchor=""/> 1681 1682 <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/> 1683 <x:anchor-alias value="302"/> 1682 1684 <x:anchor-alias value="302 (Found)"/> 1683 1685 <t> … … 1766 1768 <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/> 1767 1769 <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/> 1770 <x:anchor-alias value="307"/> 1768 1771 <x:anchor-alias value="307 (Temporary Redirect)"/> 1769 1772 <t> … … 2147 2150 <t> 2148 2151 <x:h>Note</x:h> to implementors: some deployed proxies are known to 2149 return 400 or 500 when DNS lookups time out. 2152 return <x:ref>400 (Bad Request)</x:ref> or <x:ref>500 (Internal Server 2153 Error)</x:ref> when DNS lookups time out. 2150 2154 </t> 2151 2155 </x:note> … … 2708 2712 the response payload is a representation of the target resource.</t> 2709 2713 <t>If the response status code is <x:ref>204 (No Content)</x:ref>, 2710 <x:ref>206 (Partial Content </x:ref>, or <x:ref>304 (Not Modified)</x:ref>2714 <x:ref>206 (Partial Content)</x:ref>, or <x:ref>304 (Not Modified)</x:ref> 2711 2715 and the request method was GET or HEAD, the response payload is a partial 2712 2716 representation of the target resource.</t> … … 2734 2738 Representation header fields define metadata about the representation data 2735 2739 enclosed in the message body or, if no message body is present, about 2736 the representation that would have been transferred in a 200 response2737 to a simultaneous GET request with the same effective request URI.2740 the representation that would have been transferred in a <x:ref>200 (OK)</x:ref> 2741 response to a simultaneous GET request with the same effective request URI. 2738 2742 </t> 2739 2743 <t> … … 3454 3458 as a specific identifier for the representation in this message. 3455 3459 In other words, if one were to perform a GET on this URI at the time 3456 of this message's generation, then a 200 response would contain the3457 same representation that is enclosed as payload in this message.3460 of this message's generation, then a <x:ref>200 (OK)</x:ref> response would 3461 contain the same representation that is enclosed as payload in this message. 3458 3462 </t> 3459 3463 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/> … … 3492 3496 available (for future access with GET) at the given URI. For 3493 3497 example, a purchase transaction made via a POST request might 3494 include a receipt document as the payload of the 200 response;3495 the Content-Location value provides an identifier for retrieving3498 include a receipt document as the payload of the <x:ref>200 (OK)</x:ref> 3499 response; the Content-Location value provides an identifier for retrieving 3496 3500 a copy of that same receipt in the future. 3497 3501 </t> … … 3732 3736 <t> 3733 3737 For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the 3734 new resource which was created by the request. For <x:ref>3xx </x:ref> responses, the3735 location &SHOULD; indicate the server's preferred URI for automatic3736 redirection to the resource.3738 new resource which was created by the request. For <x:ref>3xx (Redirection)</x:ref> 3739 responses, the location &SHOULD; indicate the server's preferred URI for 3740 automatic redirection to the resource. 3737 3741 </t> 3738 3742 <t> … … 5470 5474 </t> 5471 5475 <t> 5472 Status codes 301, 302, and 307: removed the normative requirements on both5473 re sponse payloads and user interaction.5476 Status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and <x:ref>307</x:ref>: 5477 removed the normative requirements on both response payloads and user interaction. 5474 5478 (<xref target="status.3xx"/>) 5475 5479 </t> … … 5479 5483 that determination based on the request method semantics. 5480 5484 Furthermore, allow user agents to rewrite the method from POST to GET 5481 for status codes 301 and 302.5485 for status codes <x:ref>301</x:ref> and <x:ref>302</x:ref>. 5482 5486 (Sections <xref format="counter" target="status.301"/>, 5483 5487 <xref format="counter" target="status.302"/> and -
draft-ietf-httpbis/latest/p3-payload.html
r1697 r1735 374 374 } 375 375 @bottom-center { 376 content: "Expires January 2, 2013";376 content: "Expires January 7, 2013"; 377 377 } 378 378 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 1">406 <meta name="dct.issued" scheme="ISO8601" content="2012-07-06"> 407 407 <meta name="dct.abstract" content="This part is now obsolete. Please see HTTPbis, Part 2."> 408 408 <meta name="description" content="This part is now obsolete. Please see HTTPbis, Part 2."> … … 424 424 </tr> 425 425 <tr> 426 <td class="left">Expires: January 2, 2013</td>426 <td class="left">Expires: January 7, 2013</td> 427 427 <td class="right">W3C</td> 428 428 </tr> … … 437 437 <tr> 438 438 <td class="left"></td> 439 <td class="right">July 1, 2012</td>439 <td class="right">July 6, 2012</td> 440 440 </tr> 441 441 </tbody> … … 453 453 in progress”. 454 454 </p> 455 <p>This Internet-Draft will expire on January 2, 2013.</p>455 <p>This Internet-Draft will expire on January 7, 2013.</p> 456 456 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 457 457 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p5-range.html
r1734 r1735 805 805 </p> 806 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 <a href="#status.206" class="smpl">206</a> responses, then the stored response with the most header fields is used as the source of header fields for the combined response,808 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 corresponding807 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 809 809 header fields in the stored response. 810 810 </p> -
draft-ietf-httpbis/latest/p5-range.xml
r1734 r1735 462 462 of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response 463 463 header fields consist of the most recent 200 response's header fields. 464 If all of the matching stored responses are <x:ref>206</x:ref>responses, then the464 If all of the matching stored responses are 206 responses, then the 465 465 stored response with the most header fields is used as the source of 466 466 header fields for the combined response, except that the client &MUST; … … 1023 1023 <x:source href="p2-semantics.xml" basename="p2-semantics"> 1024 1024 <x:defines>200 (OK)</x:defines> 1025 <x:defines>410 (Gone)</x:defines> 1025 1026 </x:source> 1026 1027 </reference> -
draft-ietf-httpbis/latest/p6-cache.html
r1734 r1735 965 965 <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4> 966 966 <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness 967 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: 200, 203, <a href="p5-range.html#status.206" class="smpl">206</a>, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it. 967 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 968 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it. 968 969 </p> 969 970 <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning … … 1092 1093 request is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s). 1093 1094 </li> 1094 <li>However, if a cache receives a 5xx response while attempting to validate a response, it can either forward this response to 1095 the requesting client, or act as if the server failed to respond. In the latter case, it can return a previously stored response 1096 (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). 1095 <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as 1096 if the server failed to respond. In the latter case, it can return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). 1097 1097 </li> 1098 1098 </ul> … … 1152 1152 <p id="rfc.section.2.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown. 1153 1153 </p> 1154 <p id="rfc.section.2.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx </a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,1154 <p id="rfc.section.2.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI, 1155 1155 or will mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent 1156 1156 request. -
draft-ietf-httpbis/latest/p6-cache.xml
r1734 r1735 683 683 If no explicit expiration time is present in a stored response that has a 684 684 status code whose definition allows heuristic freshness to be used 685 (including the following in &status-codes;: 200, 203, <x:ref>206</x:ref>, 300, 301 and 686 410), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT; 685 (including the following in &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203 686 (Non-Authoritative Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>, 687 <x:ref>300 (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and 688 <x:ref>410 (Gone)</x:ref>), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT; 687 689 use heuristics to determine freshness for responses with status codes that do 688 690 not explicitly allow it. … … 923 925 </t> 924 926 <t> 925 However, if a cache receives a 5xx response while attempting to926 validate a response, it can either forward this response to the927 requesting client, or act as if the server failed to respond. Inthe928 latter case, it can return a previously stored response (see <xref929 target="serving.stale.responses" />).927 However, if a cache receives a <x:ref>5xx (Server Error)</x:ref> 928 response while attempting to validate a response, it can either 929 forward this response to the requesting client, or act as if the 930 server failed to respond. In the latter case, it can return a 931 previously stored response (see <xref target="serving.stale.responses" />). 930 932 </t> 931 933 </list> … … 1033 1035 </t> 1034 1036 <t> 1035 Here, a "non-error response" is one with a <x:ref>2xx</x:ref> or <x:ref>3xx</x:ref> status code. 1037 Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref> or 1038 <x:ref>3xx (Redirection)</x:ref> status code. 1036 1039 "Invalidate" means that the cache will either remove all stored 1037 1040 responses related to the effective request URI, or will mark these as … … 2294 2297 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" /> 2295 2298 <x:source basename="p2-semantics" href="p2-semantics.xml"> 2296 <x:defines>2xx </x:defines>2299 <x:defines>2xx (Successful)</x:defines> 2297 2300 <x:defines>200 (OK)</x:defines> 2298 <x:defines>3xx</x:defines> 2301 <x:defines>203 (Non-Authoritative Information)</x:defines> 2302 <x:defines>3xx (Redirection)</x:defines> 2303 <x:defines>300 (Multiple Choices)</x:defines> 2304 <x:defines>301 (Moved Permanently)</x:defines> 2299 2305 <x:defines>404 (Not Found)</x:defines> 2306 <x:defines>410 (Gone)</x:defines> 2307 <x:defines>5xx (Server Error)</x:defines> 2300 2308 <x:defines>504 (Gateway Timeout)</x:defines> 2301 2309 </x:source> … … 2345 2353 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" /> 2346 2354 <x:source basename="p5-range" href="p5-range.xml"> 2347 <x:defines>206</x:defines>2348 2355 <x:defines>206 (Partial Content)</x:defines> 2349 2356 </x:source> -
draft-ietf-httpbis/latest/p7-auth.html
r1725 r1735 449 449 } 450 450 @bottom-center { 451 content: "Expires January 6, 2013";451 content: "Expires January 7, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 5">491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-06"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: January 6, 2013</td>522 <td class="left">Expires: January 7, 2013</td> 523 523 <td class="right">greenbytes</td> 524 524 </tr> 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 5, 2012</td>527 <td class="right">July 6, 2012</td> 528 528 </tr> 529 529 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on January 6, 2013.</p>555 <p>This Internet-Draft will expire on January 7, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.