Changeset 1113


Ignore:
Timestamp:
Feb 9, 2011, 9:55:58 PM (9 years ago)
Author:
mnot@…
Message:

Setting Expires in the past doesn't guarantee that caches will always validate.

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

Legend:

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

    r1112 r1113  
    813813      </p>
    814814      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past
    815          to indicate that the response is already stale. Compliant caches will validate the cached response before reusing it for subsequent
    816          requests.
     815         to indicate that the response is already stale. Compliant caches will normally validate the cached response before reusing
     816         it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
    817817      </p>
    818818      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1112 r1113  
    588588   If an origin server wishes to force a cache to validate every request, it
    589589   can assign an explicit expiration time in the past to indicate that the
    590    response is already stale.  Compliant caches will validate the cached response
    591    before reusing it for subsequent requests.
     590   response is already stale. Compliant caches will normally validate the
     591   cached response before reusing it for subsequent requests (see <xref
     592   target="serving.stale.responses" />).
    592593</t>
    593594<t>
Note: See TracChangeset for help on using the changeset viewer.