Changeset 1113
- Timestamp:
- 10/02/11 05:55:58 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1112 r1113 813 813 </p> 814 814 <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 subsequent816 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 2.3.3</a>). 817 817 </p> 818 818 <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 588 588 If an origin server wishes to force a cache to validate every request, it 589 589 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" />). 592 593 </t> 593 594 <t>
Note: See TracChangeset
for help on using the changeset viewer.