Changeset 1433 for draft-ietf-httpbis/latest
- Timestamp:
- 02/09/11 02:32:32 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.html
r1426 r1433 359 359 } 360 360 @bottom-center { 361 content: "Expires March 4, 2012";361 content: "Expires March 5, 2012"; 362 362 } 363 363 @bottom-right { … … 406 406 <meta name="dct.creator" content="Reschke, J. F."> 407 407 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 408 <meta name="dct.issued" scheme="ISO8601" content="2011-09-0 1">408 <meta name="dct.issued" scheme="ISO8601" content="2011-09-02"> 409 409 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 410 410 <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-specific requests and the rules for constructing and combining responses to those requests."> … … 432 432 </tr> 433 433 <tr> 434 <td class="left">Expires: March 4, 2012</td>434 <td class="left">Expires: March 5, 2012</td> 435 435 <td class="right">J. Mogul</td> 436 436 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">September 1, 2011</td>491 <td class="right">September 2, 2011</td> 492 492 </tr> 493 493 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on March 4, 2012.</p>519 <p>This Internet-Draft will expire on March 5, 2012.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p6-cache.xml
r1426 r1433 473 473 positive integer it can represent, or if any of its subsequent calculations 474 474 overflows, it &MUST; consider the value to be 2147483648 (2<x:sup>31</x:sup>). 475 Recipients parsing a delta-seconds value & SHOULD; use an arithmetic type of475 Recipients parsing a delta-seconds value &MUST; use an arithmetic type of 476 476 at least 31 bits of range, and senders &MUST-NOT; send delta-seconds with a 477 477 value greater than 2147483648. … … 751 751 </t> 752 752 <t> 753 Also, if the response has a Last-Modified header field (&header-last-modified;),754 a cache &SHOULD-NOT; use a heuristic expiration value that is more than some755 fraction of the interval since that time. A typical setting of this fraction756 might be 10%.753 Also, if the response has a Last-Modified header field 754 (&header-last-modified;), caches are encouraged to use a heuristic 755 expiration value that is no more than some fraction of the interval since 756 that time. A typical setting of this fraction might be 10%. 757 757 </t> 758 758 <x:note> … … 911 911 </t> 912 912 <t> 913 A cache & SHOULD-NOT; return stale responses unless it is disconnected913 A cache &MUST-NOT; return stale responses unless it is disconnected 914 914 (i.e., it cannot contact the origin server or otherwise find a forward 915 915 path) or doing so is explicitly allowed (e.g., by the max-stale request … … 926 926 304 (Not Modified) response) that it would normally forward to the 927 927 requesting client, and the received response is no longer fresh, the cache 928 &SHOULD; forward it to the requesting client without adding a new Warning929 (but without removing any existing Warning header fields). A cache &SHOULD-NOT;928 can forward it to the requesting client without adding a new Warning (but 929 without removing any existing Warning header fields). A cache shouldn't 930 930 attempt to validate a response simply because that response became stale in 931 931 transit. … … 945 945 </t> 946 946 <t> 947 When sending such a conditional request, a cache &SHOULD; add an948 If-Modified-Since header field whose value is that of the Last-Modified header949 field from the selected (see <xref target="caching.negotiated.responses"/>)950 storedresponse, if available.951 </t> 952 <t> 953 Additionally, a cache &SHOULD;add an If-None-Match header field whose value is954 that of the ETag header field(s) from all responses stored for the requested URI,955 if present. However, if any of the stored responses contains only partial956 content, the cache &SHOULD-NOT; include its entity-tag in the If-None-Match957 header field unless the request is for a range that would be fully958 satisfied by that stored response.947 When sending such a conditional request, a cache adds an If-Modified-Since 948 header field whose value is that of the Last-Modified header field from the 949 selected (see <xref target="caching.negotiated.responses"/>) stored 950 response, if available. 951 </t> 952 <t> 953 Additionally, a cache can add an If-None-Match header field whose value is 954 that of the ETag header field(s) from all responses stored for the 955 requested URI, if present. However, if any of the stored responses contains 956 only partial content, the cache shouldn't include its entity-tag in the 957 If-None-Match header field unless the request is for a range that would be 958 fully satisfied by that stored response. 959 959 </t> 960 960 … … 971 971 A full response (i.e., one with a response body) indicates that none 972 972 of the stored responses nominated in the conditional request is 973 suitable. Instead, a cache &SHOULD; use the full response to satisfy974 the request and &MAY; replace the stored response(s).973 suitable. Instead, the cache can use the full response to 974 satisfy the request and &MAY; replace the stored response(s). 975 975 </t> 976 976 <t> 977 977 However, if a cache receives a 5xx response while attempting to 978 validate a response, it &MAY;either forward this response to the978 validate a response, it can either forward this response to the 979 979 requesting client, or act as if the server failed to respond. In the 980 latter case, it &MAY;return a previously stored response (see <xref980 latter case, it can return a previously stored response (see <xref 981 981 target="serving.stale.responses" />). 982 982 </t> … … 1048 1048 </t> 1049 1049 <t> 1050 A cache & SHOULD; invalidate the effective request URI1050 A cache &MUST; invalidate the effective request URI 1051 1051 (&effective-request-uri;) when it receives a non-error response 1052 1052 to a request with a method whose safety is unknown. … … 1141 1141 </t> 1142 1142 <t> 1143 If no selected response is available, the cache &MAY;forward the presented1143 If no selected response is available, the cache can forward the presented 1144 1144 request to the origin server in a conditional request; see <xref 1145 1145 target="validation.model"/>. … … 1466 1466 if a cache cannot reach the origin server for any reason, it &MUST; 1467 1467 generate a 504 (Gateway Timeout) response.</t> 1468 <t> A server &SHOULD; send the must-revalidate directive if and only if1469 failure to validate a request on the representation could result in1468 <t>The must-revalidate directive ought to be used by servers if and only 1469 if failure to validate a request on the representation could result in 1470 1470 incorrect operation, such as a silently unexecuted financial 1471 1471 transaction.</t> … … 1664 1664 </t> 1665 1665 <t> 1666 When sending a no-cache request, a client &SHOULD; include both pragma and1667 cache-control directives unless Cache-Control: no-cache is purposefully1668 omitted to target other Cache-Control response directives at HTTP/1.11669 caches. For example:1666 When sending a no-cache request, a client ought to include both the pragma 1667 and cache-control directives, unless Cache-Control: no-cache is 1668 purposefully omitted to target other Cache-Control response directives at 1669 HTTP/1.1 caches. For example: 1670 1670 </t> 1671 1671 <figure> … … 1791 1791 </t> 1792 1792 <t> 1793 Systems that generate multiple Warning header fields &SHOULD; order them with1794 this user agent behavior in mind. New Warning header fields &SHOULD; be added1795 a fter any existing Warning headers fields.1793 Systems that generate multiple Warning header fields are encouraged to 1794 order them with this user agent behavior in mind. New Warning header fields 1795 are added after any existing Warning headers fields. 1796 1796 </t> 1797 1797 <t> … … 1845 1845 112 Disconnected operation 1846 1846 <list> 1847 <t>A cache &SHOULD; binclude this if it is intentionally disconnected from1847 <t>A cache &SHOULD; include this if it is intentionally disconnected from 1848 1848 the rest of the network for a period of time.</t> 1849 1849 </list>
Note: See TracChangeset
for help on using the changeset viewer.