Changeset 2235 for draft-ietf-httpbis/latest/p6-cache.html

Timestamp:

07/05/13 06:17:49 (10 years ago)

Author:

mnot@…

Message:

Move date parsing advice up to freshness; see #469

File:

• draft-ietf-httpbis/latest/p6-cache.html (modified) (2 diffs)

draft-ietf-httpbis/latest/p6-cache.html

@@ -917 +917 @@
          corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
       </p>
-      <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
+      <p id="rfc.section.4.1.p.8">When calculating freshness, to avoid common problems in date parsing:</p>
+      <p id="rfc.section.4.1.p.9"> </p>
+      <ul>
+         <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.
+         </li>
+         <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.
+         </li>
+         <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.
+         </li>
+         <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
+         </li>
+      </ul>
+      <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
          a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;8</a> for an explanation of the difference between caches and history mechanisms.
       </p>
@@ -1015 +1027 @@
       <div id="rfc.figure.u.5"></div><pre class="text">  resident_time = now - response_time;
   current_age = corrected_initial_age + resident_time;
-</pre><p id="rfc.section.4.1.3.p.14">Additionally, to avoid common problems in date parsing:</p>
-      <p id="rfc.section.4.1.3.p.15"> </p>
-      <ul>
-         <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.
-         </li>
-         <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.
-         </li>
-         <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.
-         </li>
-         <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
-         </li>
-      </ul>
-      <h3 id="rfc.section.4.1.4"><a href="#rfc.section.4.1.4">4.1.4</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
+</pre><h3 id="rfc.section.4.1.4"><a href="#rfc.section.4.1.4">4.1.4</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
       <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
          is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>.