Changeset 2082 for draft-ietf-httpbis/latest/p6-cache.xml

Timestamp:

04/01/13 10:29:06 (9 years ago)

Author:

fielding@…

Message:

Yet another attempt to explain HTTP-date, remove redundant requirements in sections that use HTTP-date, and correct some inconsistent requirements regarding time zones; related to #375 and [2077]

File:

• draft-ietf-httpbis/latest/p6-cache.xml (modified) (8 diffs)

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

@@ -527 +527 @@
 <t>
    A cache that does not have a clock available &MUST-NOT; use stored
-   responses without revalidating them on every use. A cache, especially a
-   shared cache, &SHOULD; use a mechanism, such as NTP <xref
-   target="RFC1305"/>, to synchronize its clock with a reliable external
-   standard.
+   responses without revalidating them on every use.
 </t>
 
@@ -659 +656 @@
 <section anchor="age.calculations" title="Calculating Age">
 <t>
-   HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated
+   The <x:ref>Age</x:ref> header field is used to convey an estimated
    age of the response message when obtained from a cache. The Age field value
-   is the cache's estimate of the amount of time since the response was
+   is the cache's estimate of the number of seconds since the response was
    generated or validated by the origin server. In essence, the Age value is
    the sum of the time that the response has been resident in each of the
@@ -684 +681 @@
    <list>
       <t>
-         HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header
-         field, if possible, with every response, giving the time at which the
-         response was generated. The term "date_value" denotes the value of
+         The term "date_value" denotes the value of
          the Date header field, in a form appropriate for arithmetic
          operations. See &header-date; for the definition of the Date header
@@ -698 +693 @@
       <t>
          The term "now" means "the current value of the clock at the host
-         performing the calculation". A cache &SHOULD; use NTP (<xref
+         performing the calculation". A host ought to use NTP (<xref
          target="RFC1305"/>) or some similar protocol to synchronize its
-         clocks to a globally accurate time standard.
+         clocks to Coordinated Universal Time.
       </t>
    </list>
@@ -766 +761 @@
 <t>
   <list style="symbols">
-     <t>Recipients &SHOULD; assume that an RFC-850 date
-        appearing to be more than 50 years in the future is in fact
-        in the past (this helps solve the "year 2000" problem).</t>
-
      <t>Although all date formats are specified to be case-sensitive, 
-        recipients &SHOULD; match day, week and timezone names
+        cache recipients &SHOULD; match day, week and timezone names
         case-insensitively.</t>
              
-     <t>An implementation &MAY; internally represent a parsed
-        <x:ref>Expires</x:ref> date as earlier than the proper value, but
-        &MUST-NOT; internally represent a parsed Expires date as later than the
-        proper value.</t>
-
-     <t>Recipients &MUST; perform all expiration-related calculations in GMT.
-        The local time zone &MUST-NOT; influence the calculation or comparison
-        of an age or expiration time.</t>
-
-     <t>Caches &SHOULD; consider dates with time zones other than "GMT"
-        invalid.</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>
@@ -1592 +1582 @@
 </t>
 <t>
-   The field-value is an absolute date and time as defined by HTTP-date in
-   &http-date;; a sender &MUST; use the rfc1123-date format.
+   The Expires value is an HTTP-date timestamp, as defined in &http-date;.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/>
@@ -1604 +1593 @@
 </artwork></figure>
 <t>
-   A cache &MUST; treat other invalid date formats,
-   especially including the value "0", as in the past (i.e., "already
-   expired").
-</t>
-<x:note>
-   <t>
-       &Note; If a response includes a <x:ref>Cache-Control</x:ref> field with
-       the max-age directive (see <xref target="cache-response-directive.max-age" />),
-       that directive overrides the Expires field. Likewise, the s-maxage
-       directive (<xref target="cache-response-directive.s-maxage" />) overrides
-       the <x:ref>Expires</x:ref> header field in shared caches.
-   </t>
-</x:note>
+   A cache recipient &MUST; interpret invalid date formats, especially the
+   value "0", as representing a time in the past (i.e., "already expired").
+</t>
+<t>
+   If a response includes a <x:ref>Cache-Control</x:ref> field with
+   the max-age directive (<xref target="cache-response-directive.max-age"/>),
+   a recipient &MUST; ignore the Expires field.
+   Likewise, if a response includes the s-maxage directive
+   (<xref target="cache-response-directive.s-maxage" />), a shared cache
+   recipient &MUST; ignore the Expires field. In both these cases, the value
+   in Expires is only intended for recipients that have not yet implemented
+   the Cache-Control field.
+</t>
+<t>
+   An origin server without a clock &MUST-NOT; generate an Expires field
+   unless its value represents a fixed time in the past (always expired)
+   or its value has been associated with the resource by a system or user
+   with a reliable clock.
+</t>
 <t>
    Historically, HTTP required the Expires field-value to be no more than a 
@@ -1624 +1619 @@
    time values), and many caches will evict a response far sooner than 
    that.
-</t>
-<t>
-   An origin server without a clock &MUST-NOT; assign Expires
-   values to a response unless these values were associated
-   with the resource by a system or user with a reliable clock. It &MAY;
-   assign an Expires value that is known, at or before server
-   configuration time, to be in the past (this allows "pre-expiration"
-   of responses without storing separate Expires values for each
-   resource).
 </t>
 </section>