Changeset 2235 for draft-ietf-httpbis/latest

Timestamp:

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

Author:

mnot@…

Message:

Move date parsing advice up to freshness; see #469

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (2 diffs)
• p6-cache.xml (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>.

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

@@ -579 +579 @@
 </t>
 <t>
+   When calculating freshness, to avoid common problems in date parsing:
+</t>
+<t>
+  <list style="symbols">
+     <t>Although all date formats are specified to be case-sensitive, 
+        cache recipients &SHOULD; match day, week and timezone names
+        case-insensitively.</t>
+             
+     <t>If a cache recipient's internal implementation of time has less
+        resolution than the value of an HTTP-date, the recipient &MUST;
+        internally represent a parsed <x:ref>Expires</x:ref> date as the
+        nearest time equal to or earlier than the received value.</t>
+
+     <t>Cache recipients &MUST-NOT; allow local time zones to influence the
+        calculation or comparison of an age or expiration time.</t>
+
+     <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
+        other than "GMT" to be invalid for calculating expiration.</t>
+  </list>
+</t>
+<t>
    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 <xref
@@ -761 +782 @@
   current_age = corrected_initial_age + resident_time;
 </artwork></figure>
-<t>
-   Additionally, to avoid common problems in date parsing:
-</t>
-<t>
-  <list style="symbols">
-     <t>Although all date formats are specified to be case-sensitive, 
-        cache recipients &SHOULD; match day, week and timezone names
-        case-insensitively.</t>
-             
-     <t>If a cache recipient's internal implementation of time has less
-        resolution than the value of an HTTP-date, the recipient &MUST;
-        internally represent a parsed <x:ref>Expires</x:ref> date as the
-        nearest time equal to or earlier than the received value.</t>
-
-     <t>Cache recipients &MUST-NOT; allow local time zones to influence the
-        calculation or comparison of an age or expiration time.</t>
-
-     <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
-        other than "GMT" to be invalid for calculating expiration.</t>
-  </list>
-</t>
 </section>