Changeset 2235


Ignore:
Timestamp:
May 6, 2013, 11:17:49 PM (6 years ago)
Author:
mnot@…
Message:

Move date parsing advice up to freshness; see #469

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r2234 r2235  
    917917         corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
    918918      </p>
    919       <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
     919      <p id="rfc.section.4.1.p.8">When calculating freshness, to avoid common problems in date parsing:</p>
     920      <p id="rfc.section.4.1.p.9"> </p>
     921      <ul>
     922         <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.
     923         </li>
     924         <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.
     925         </li>
     926         <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.
     927         </li>
     928         <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
     929         </li>
     930      </ul>
     931      <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
    920932         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.
    921933      </p>
     
    10151027      <div id="rfc.figure.u.5"></div><pre class="text">  resident_time = now - response_time;
    10161028  current_age = corrected_initial_age + resident_time;
    1017 </pre><p id="rfc.section.4.1.3.p.14">Additionally, to avoid common problems in date parsing:</p>
    1018       <p id="rfc.section.4.1.3.p.15"> </p>
    1019       <ul>
    1020          <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.
    1021          </li>
    1022          <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.
    1023          </li>
    1024          <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.
    1025          </li>
    1026          <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
    1027          </li>
    1028       </ul>
    1029       <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>
     1029</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>
    10301030      <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
    10311031         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

    r2234 r2235  
    579579</t>
    580580<t>
     581   When calculating freshness, to avoid common problems in date parsing:
     582</t>
     583<t>
     584  <list style="symbols">
     585     <t>Although all date formats are specified to be case-sensitive,
     586        cache recipients &SHOULD; match day, week and timezone names
     587        case-insensitively.</t>
     588             
     589     <t>If a cache recipient's internal implementation of time has less
     590        resolution than the value of an HTTP-date, the recipient &MUST;
     591        internally represent a parsed <x:ref>Expires</x:ref> date as the
     592        nearest time equal to or earlier than the received value.</t>
     593
     594     <t>Cache recipients &MUST-NOT; allow local time zones to influence the
     595        calculation or comparison of an age or expiration time.</t>
     596
     597     <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
     598        other than "GMT" to be invalid for calculating expiration.</t>
     599  </list>
     600</t>
     601<t>
    581602   Note that freshness applies only to cache operation; it cannot be used to
    582603   force a user agent to refresh its display or reload a resource. See <xref
     
    761782  current_age = corrected_initial_age + resident_time;
    762783</artwork></figure>
    763 <t>
    764    Additionally, to avoid common problems in date parsing:
    765 </t>
    766 <t>
    767   <list style="symbols">
    768      <t>Although all date formats are specified to be case-sensitive,
    769         cache recipients &SHOULD; match day, week and timezone names
    770         case-insensitively.</t>
    771              
    772      <t>If a cache recipient's internal implementation of time has less
    773         resolution than the value of an HTTP-date, the recipient &MUST;
    774         internally represent a parsed <x:ref>Expires</x:ref> date as the
    775         nearest time equal to or earlier than the received value.</t>
    776 
    777      <t>Cache recipients &MUST-NOT; allow local time zones to influence the
    778         calculation or comparison of an age or expiration time.</t>
    779 
    780      <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
    781         other than "GMT" to be invalid for calculating expiration.</t>
    782   </list>
    783 </t>
    784784</section>
    785785
Note: See TracChangeset for help on using the changeset viewer.