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.html

    r2080 r2082  
    452452  }
    453453  @bottom-center {
    454        content: "Expires July 6, 2013";
     454       content: "Expires July 8, 2013";
    455455  }
    456456  @bottom-right {
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
     500      <meta name="dct.issued" scheme="ISO8601" content="2013-01-04">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 6, 2013</td>
     526               <td class="left">Expires: July 8, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">January 2, 2013</td>
     535               <td class="right">January 4, 2013</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on July 6, 2013.</p>
     561      <p>This Internet-Draft will expire on July 8, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    894894         which response to use.
    895895      </p>
    896       <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.
     896      <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use.
    897897      </p>
    898898      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
     
    957957      </div>
    958958      <h3 id="rfc.section.4.1.3"><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
    959       <p id="rfc.section.4.1.3.p.1">HTTP/1.1 uses the <a href="#header.age" class="smpl">Age</a> header field to convey the estimated age of the response message when obtained from a cache. The Age field value is the cache's
    960          estimate of the amount of time since the response was generated or validated by the origin server. In essence, the Age value
    961          is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus
    962          the amount of time it has been in transit along network paths.
     959      <p id="rfc.section.4.1.3.p.1">The <a href="#header.age" class="smpl">Age</a> header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is
     960         the cache's estimate of the number of seconds since the response was generated or validated by the origin server. In essence,
     961         the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin
     962         server, plus the amount of time it has been in transit along network paths.
    963963      </p>
    964964      <p id="rfc.section.4.1.3.p.2">The following data is used for the age calculation:</p>
     
    972972      </p>
    973973      <ul class="empty">
    974          <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value"
    975             denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     974         <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    976975         </li>
    977976      </ul>
     
    979978      </p>
    980979      <ul class="empty">
    981          <li>The term "now" means "the current value of the clock at the host performing the calculation". A cache <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.2"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clocks to a globally accurate time standard.
     980         <li>The term "now" means "the current value of the clock at the host performing the calculation". A host ought to use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clocks to Coordinated Universal Time.
    982981         </li>
    983982      </ul>
     
    10171016      <p id="rfc.section.4.1.3.p.15"> </p>
    10181017      <ul>
    1019          <li>Recipients <em class="bcp14">SHOULD</em> 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
    1020             "year 2000" problem).
    1021          </li>
    1022          <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
    1023          </li>
    1024          <li>An implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.
    1025          </li>
    1026          <li>Recipients <em class="bcp14">MUST</em> perform all expiration-related calculations in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
    1027          </li>
    1028          <li>Caches <em class="bcp14">SHOULD</em> consider dates with time zones other than "GMT" invalid.
     1018         <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.
     1019         </li>
     1020         <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.
     1021         </li>
     1022         <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.
     1023         </li>
     1024         <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
    10291025         </li>
    10301026      </ul>
     
    14231419         that time.
    14241420      </p>
    1425       <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
     1421      <p id="rfc.section.7.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    14261422      </p>
    14271423      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    14281424</pre><div id="rfc.figure.u.10"></div>
    14291425      <p>For example</p>  <pre class="text">  Expires: Thu, 01 Dec 1994 16:00:00 GMT
    1430 </pre><p id="rfc.section.7.3.p.6">A cache <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
    1431       </p>
    1432       <div class="note" id="rfc.section.7.3.p.7">
    1433          <p> <b>Note:</b> If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (see <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.7</a>), that directive overrides the Expires field. Likewise, the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.8</a>) overrides the <a href="#header.expires" class="smpl">Expires</a> header field in shared caches.
    1434          </p>
    1435       </div>
    1436       <p id="rfc.section.7.3.p.8">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes
     1426</pre><p id="rfc.section.7.3.p.6">A cache recipient <em class="bcp14">MUST</em> interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
     1427      </p>
     1428      <p id="rfc.section.7.3.p.7">If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.7</a>), a recipient <em class="bcp14">MUST</em> ignore the Expires field. Likewise, if a response includes the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.8</a>), a shared cache recipient <em class="bcp14">MUST</em> ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented
     1429         the Cache-Control field.
     1430      </p>
     1431      <p id="rfc.section.7.3.p.8">An origin server without a clock <em class="bcp14">MUST NOT</em> generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated
     1432         with the resource by a system or user with a reliable clock.
     1433      </p>
     1434      <p id="rfc.section.7.3.p.9">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes
    14371435         are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use
    14381436         of 32-bit integers for time values), and many caches will evict a response far sooner than that.
    1439       </p>
    1440       <p id="rfc.section.7.3.p.9">An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires values to a response unless these values were associated with the resource by a system or user with a reliable
    1441          clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration"
    1442          of responses without storing separate Expires values for each resource).
    14431437      </p>
    14441438      <div id="rfc.iref.p.5"></div>
     
    21752169            </li>
    21762170            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    2177                   <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4</a>, <a href="#rfc.xref.RFC1305.2">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
     2171                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
    21782172                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.3</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    21792173                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.1.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul>
Note: See TracChangeset for help on using the changeset viewer.