Ignore:
Timestamp:
Jan 4, 2013, 2:29:06 AM (7 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:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2080 r2082  
    527527<t>
    528528   A cache that does not have a clock available &MUST-NOT; use stored
    529    responses without revalidating them on every use. A cache, especially a
    530    shared cache, &SHOULD; use a mechanism, such as NTP <xref
    531    target="RFC1305"/>, to synchronize its clock with a reliable external
    532    standard.
     529   responses without revalidating them on every use.
    533530</t>
    534531
    … …  
    659656<section anchor="age.calculations" title="Calculating Age">
    660657<t>
    661    HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated
     658   The <x:ref>Age</x:ref> header field is used to convey an estimated
    662659   age of the response message when obtained from a cache. The Age field value
    663    is the cache's estimate of the amount of time since the response was
     660   is the cache's estimate of the number of seconds since the response was
    664661   generated or validated by the origin server. In essence, the Age value is
    665662   the sum of the time that the response has been resident in each of the
    … …  
    684681   <list>
    685682      <t>
    686          HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header
    687          field, if possible, with every response, giving the time at which the
    688          response was generated. The term "date_value" denotes the value of
     683         The term "date_value" denotes the value of
    689684         the Date header field, in a form appropriate for arithmetic
    690685         operations. See &header-date; for the definition of the Date header
    … …  
    698693      <t>
    699694         The term "now" means "the current value of the clock at the host
    700          performing the calculation". A cache &SHOULD; use NTP (<xref
     695         performing the calculation". A host ought to use NTP (<xref
    701696         target="RFC1305"/>) or some similar protocol to synchronize its
    702          clocks to a globally accurate time standard.
     697         clocks to Coordinated Universal Time.
    703698      </t>
    704699   </list>
    … …  
    766761<t>
    767762  <list style="symbols">
    768      <t>Recipients &SHOULD; assume that an RFC-850 date
    769         appearing to be more than 50 years in the future is in fact
    770         in the past (this helps solve the "year 2000" problem).</t>
    771 
    772763     <t>Although all date formats are specified to be case-sensitive,
    773         recipients &SHOULD; match day, week and timezone names
     764        cache recipients &SHOULD; match day, week and timezone names
    774765        case-insensitively.</t>
    775766             
    776      <t>An implementation &MAY; internally represent a parsed
    777         <x:ref>Expires</x:ref> date as earlier than the proper value, but
    778         &MUST-NOT; internally represent a parsed Expires date as later than the
    779         proper value.</t>
    780 
    781      <t>Recipients &MUST; perform all expiration-related calculations in GMT.
    782         The local time zone &MUST-NOT; influence the calculation or comparison
    783         of an age or expiration time.</t>
    784 
    785      <t>Caches &SHOULD; consider dates with time zones other than "GMT"
    786         invalid.</t>
     767     <t>If a cache recipient's internal implementation of time has less
     768        resolution than the value of an HTTP-date, the recipient &MUST;
     769        internally represent a parsed <x:ref>Expires</x:ref> date as the
     770        nearest time equal to or earlier than the received value.</t>
     771
     772     <t>Cache recipients &MUST-NOT; allow local time zones to influence the
     773        calculation or comparison of an age or expiration time.</t>
     774
     775     <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
     776        other than "GMT" to be invalid for calculating expiration.</t>
    787777  </list>
    788778</t>
    … …  
    15921582</t>
    15931583<t>
    1594    The field-value is an absolute date and time as defined by HTTP-date in
    1595    &http-date;; a sender &MUST; use the rfc1123-date format.
     1584   The Expires value is an HTTP-date timestamp, as defined in &http-date;.
    15961585</t>
    15971586<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/>
    … …  
    16041593</artwork></figure>
    16051594<t>
    1606    A cache &MUST; treat other invalid date formats,
    1607    especially including the value "0", as in the past (i.e., "already
    1608    expired").
    1609 </t>
    1610 <x:note>
    1611    <t>
    1612        &Note; If a response includes a <x:ref>Cache-Control</x:ref> field with
    1613        the max-age directive (see <xref target="cache-response-directive.max-age" />),
    1614        that directive overrides the Expires field. Likewise, the s-maxage
    1615        directive (<xref target="cache-response-directive.s-maxage" />) overrides
    1616        the <x:ref>Expires</x:ref> header field in shared caches.
    1617    </t>
    1618 </x:note>
     1595   A cache recipient &MUST; interpret invalid date formats, especially the
     1596   value "0", as representing a time in the past (i.e., "already expired").
     1597</t>
     1598<t>
     1599   If a response includes a <x:ref>Cache-Control</x:ref> field with
     1600   the max-age directive (<xref target="cache-response-directive.max-age"/>),
     1601   a recipient &MUST; ignore the Expires field.
     1602   Likewise, if a response includes the s-maxage directive
     1603   (<xref target="cache-response-directive.s-maxage" />), a shared cache
     1604   recipient &MUST; ignore the Expires field. In both these cases, the value
     1605   in Expires is only intended for recipients that have not yet implemented
     1606   the Cache-Control field.
     1607</t>
     1608<t>
     1609   An origin server without a clock &MUST-NOT; generate an Expires field
     1610   unless its value represents a fixed time in the past (always expired)
     1611   or its value has been associated with the resource by a system or user
     1612   with a reliable clock.
     1613</t>
    16191614<t>
    16201615   Historically, HTTP required the Expires field-value to be no more than a
    … …  
    16241619   time values), and many caches will evict a response far sooner than
    16251620   that.
    1626 </t>
    1627 <t>
    1628    An origin server without a clock &MUST-NOT; assign Expires
    1629    values to a response unless these values were associated
    1630    with the resource by a system or user with a reliable clock. It &MAY;
    1631    assign an Expires value that is known, at or before server
    1632    configuration time, to be in the past (this allows "pre-expiration"
    1633    of responses without storing separate Expires values for each
    1634    resource).
    16351621</t>
    16361622</section>
Note: See TracChangeset for help on using the changeset viewer.