Changeset 1113

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:

• p6-cache.html (modified) (1 diff)
• p6-cache.xml (modified) (1 diff)

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

@@ -813 +813 @@
       </p>
       <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
-         to indicate that the response is already stale. Compliant caches will validate the cached response before reusing it for subsequent
-         requests.
+         to indicate that the response is already stale. Compliant caches will normally validate the cached response before reusing
+         it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
       </p>
       <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

@@ -588 +588 @@
    If an origin server wishes to force a cache to validate every request, it
    can assign an explicit expiration time in the past to indicate that the
-   response is already stale.  Compliant caches will validate the cached response
-   before reusing it for subsequent requests.
+   response is already stale. Compliant caches will normally validate the 
+   cached response before reusing it for subsequent requests (see <xref
+   target="serving.stale.responses" />).
 </t>
 <t>