Changeset 2247 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 08/05/13 13:06:21 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r2246 r2247 452 452 } 453 453 @bottom-center { 454 content: "Expires November 8, 2013";454 content: "Expires November 9, 2013"; 455 455 } 456 456 @bottom-right { … … 492 492 <link href="p5-range.html" rel="prev"> 493 493 <link href="p7-auth.html" rel="next"> 494 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 8.9from Saxonica http://www.saxonica.com/">494 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/"> 495 495 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 496 496 <meta name="dct.creator" content="Fielding, R."> … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2013-05-0 7">500 <meta name="dct.issued" scheme="ISO8601" content="2013-05-08"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: November 8, 2013</td>526 <td class="left">Expires: November 9, 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">May 7, 2013</td>535 <td class="right">May 8, 2013</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on November 8, 2013.</p>561 <p>This Internet-Draft will expire on November 9, 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 720 720 <p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p> 721 721 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a> 722 </pre><p id="rfc.section.1.2.1.p.3">If a n implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of723 its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> senddelta-seconds with a value greater than 2147483648.722 </pre><p id="rfc.section.1.2.1.p.3">If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent 723 calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> generate delta-seconds with a value greater than 2147483648. 724 724 </p> 725 725 <div id="rfc.iref.c.2"></div> … … 737 737 <div id="rfc.iref.c.4"></div> 738 738 <p id="rfc.section.2.p.3">The primary <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching 739 responses to GET, many implementations simply decline other methods and use only the URI as the primary cache key.739 responses to GET, many caches simply decline other methods and use only the URI as the primary cache key. 740 740 </p> 741 741 <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated … … 998 998 is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section 4.1</a>. 999 999 </p> 1000 <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> senda stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache1000 <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 1001 1001 directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 1002 1002 see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 7.2.2</a>). … … 1008 1008 </p> 1009 1009 <div id="rfc.iref.f.3"></div> 1010 <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache 1011 can forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because 1010 <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">MAY</em> forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because 1012 1011 that response became stale in transit. 1013 1012 </p> … … 1047 1046 <ul> 1048 1047 <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same 1049 strong validator are selected. If none of the stored responses contain the same strong validator, then the new response <em class="bcp14">MUST NOT</em> be usedto update any stored responses.1048 strong validator are selected. If none of the stored responses contain the same strong validator, then the cache <em class="bcp14">MUST NOT</em> use the new response to update any stored responses. 1050 1049 </li> 1051 1050 <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then … … 1259 1258 <p id="rfc.section.7.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p> 1260 1259 <p id="rfc.section.7.2.2.2.p.5"> <b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive. 1261 Also, no-cache response directives with field-names are often handled by implementations as if an unqualified no-cache directive1262 wasreceived; i.e., the special handling for the qualified form is not widely implemented.1260 Also, no-cache response directives with field-names are often handled by caches as if an unqualified no-cache directive was 1261 received; i.e., the special handling for the qualified form is not widely implemented. 1263 1262 </p> 1264 1263 <p id="rfc.section.7.2.2.2.p.6"> <b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists). … … 1294 1293 <p id="rfc.section.7.2.2.6.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p> 1295 1294 <p id="rfc.section.7.2.2.6.p.5"> <b>Note:</b> This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message 1296 content. Also, private response directives with field-names are often handled by implementations as if an unqualified private1297 directivewas received; i.e., the special handling for the qualified form is not widely implemented.1295 content. Also, private response directives with field-names are often handled by caches as if an unqualified private directive 1296 was received; i.e., the special handling for the qualified form is not widely implemented. 1298 1297 </p> 1299 1298 <p id="rfc.section.7.2.2.6.p.6"> <b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists). … … 1400 1399 <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a> 1401 1400 <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#imported.abnf" class="smpl">token</a> [ "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> ) ] 1402 </pre><p id="rfc.section.7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on cachesas if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>).1401 </pre><p id="rfc.section.7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, caches <em class="bcp14">MUST</em> consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>). 1403 1402 </p> 1404 1403 <p id="rfc.section.7.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:
Note: See TracChangeset
for help on using the changeset viewer.