Changeset 2235 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 07/05/13 06:17:49 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r2234 r2235 917 917 corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>). 918 918 </p> 919 <p id="rfc.section.4.1.p.8">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload 919 <p id="rfc.section.4.1.p.8">When calculating freshness, to avoid common problems in date parsing:</p> 920 <p id="rfc.section.4.1.p.9"> </p> 921 <ul> 922 <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. 923 </li> 924 <li>If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient <em class="bcp14">MUST</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as the nearest time equal to or earlier than the received value. 925 </li> 926 <li>Cache recipients <em class="bcp14">MUST NOT</em> allow local time zones to influence the calculation or comparison of an age or expiration time. 927 </li> 928 <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration. 929 </li> 930 </ul> 931 <p id="rfc.section.4.1.p.10">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload 920 932 a resource. See <a href="#history.lists" title="History Lists">Section 8</a> for an explanation of the difference between caches and history mechanisms. 921 933 </p> … … 1015 1027 <div id="rfc.figure.u.5"></div><pre class="text"> resident_time = now - response_time; 1016 1028 current_age = corrected_initial_age + resident_time; 1017 </pre><p id="rfc.section.4.1.3.p.14">Additionally, to avoid common problems in date parsing:</p> 1018 <p id="rfc.section.4.1.3.p.15"> </p> 1019 <ul> 1020 <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. 1021 </li> 1022 <li>If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient <em class="bcp14">MUST</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as the nearest time equal to or earlier than the received value. 1023 </li> 1024 <li>Cache recipients <em class="bcp14">MUST NOT</em> allow local time zones to influence the calculation or comparison of an age or expiration time. 1025 </li> 1026 <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration. 1027 </li> 1028 </ul> 1029 <h3 id="rfc.section.4.1.4"><a href="#rfc.section.4.1.4">4.1.4</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3> 1029 </pre><h3 id="rfc.section.4.1.4"><a href="#rfc.section.4.1.4">4.1.4</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3> 1030 1030 <p id="rfc.section.4.1.4.p.1">A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but 1031 1031 is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section 4.1</a>.
Note: See TracChangeset
for help on using the changeset viewer.