Changeset 2247 for draft-ietf-httpbis/latest
- Timestamp:
- 08/05/13 13:06:21 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 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: -
draft-ietf-httpbis/latest/p6-cache.xml
r2246 r2247 204 204 </artwork></figure> 205 205 <t> 206 If a n implementationreceives a delta-seconds value larger than the largest206 If a cache receives a delta-seconds value larger than the largest 207 207 positive integer it can represent, or if any of its subsequent calculations 208 208 overflows, it &MUST; consider the value to be 2147483648 209 209 (2<x:sup>31</x:sup>). Recipients parsing a delta-seconds value &MUST; use 210 210 an arithmetic type of at least 31 bits of range, and senders &MUST-NOT; 211 senddelta-seconds with a value greater than 2147483648.211 generate delta-seconds with a value greater than 2147483648. 212 212 </t> 213 213 </section> … … 246 246 The primary <x:dfn>cache key</x:dfn> consists of the request method and 247 247 target URI. However, since HTTP caches in common use today are typically 248 limited to caching responses to GET, many implementations simply decline248 limited to caching responses to GET, many caches simply decline 249 249 other methods and use only the URI as the primary cache key. 250 250 </t> … … 736 736 </t> 737 737 <t> 738 A cache &MUST-NOT; senda stale response if it is prohibited by an738 A cache &MUST-NOT; generate a stale response if it is prohibited by an 739 739 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 740 740 directive, a "must-revalidate" cache-response-directive, or an applicable … … 760 760 an entire response, or a <x:ref>304 (Not Modified)</x:ref> response) that 761 761 it would normally forward to the requesting client, and the received 762 response is no longer fresh, the cache canforward it to the requesting762 response is no longer fresh, the cache &MAY; forward it to the requesting 763 763 client without adding a new <x:ref>Warning</x:ref> (but without removing 764 764 any existing Warning header fields). A cache shouldn't attempt to validate … … 845 845 &weak-and-strong;), then that strong validator identifies the selected 846 846 representation for update. All of the stored responses with the same 847 strong validator are selected. If none of the stored responses contain 848 the same strong validator, then the new response &MUST-NOT; be usedto847 strong validator are selected. If none of the stored responses contain the 848 same strong validator, then the cache &MUST-NOT; use the new response to 849 849 update any stored responses. 850 850 </t> … … 1283 1283 &Note; Although it has been back-ported to many implementations, some 1284 1284 HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache 1285 response directives with field-names are often handled by implementations1285 response directives with field-names are often handled by caches 1286 1286 as if an unqualified no-cache directive was received; i.e., the special 1287 1287 handling for the qualified form is not widely implemented. … … 1367 1367 where the response can be stored; it cannot ensure the privacy of the 1368 1368 message content. Also, private response directives with field-names are 1369 often handled by implementations as if an unqualified private directive1369 often handled by caches as if an unqualified private directive 1370 1370 was received; i.e., the special handling for the qualified form is not 1371 1371 widely implemented. … … 1579 1579 <t> 1580 1580 When the <x:ref>Cache-Control</x:ref> header field is not present in a 1581 request, the no-cache request pragma-directive &MUST; have the same effect1582 on caches as if "Cache-Control: no-cache" were present (see <xref1583 target="cache-request-directive" />).1581 request, caches &MUST; consider the no-cache request pragma-directive as 1582 having the same effect as if "Cache-Control: no-cache" were present (see 1583 <xref target="cache-request-directive" />). 1584 1584 </t> 1585 1585 <t>
Note: See TracChangeset
for help on using the changeset viewer.