Changeset 478


Ignore:
Timestamp:
Mar 3, 2009, 7:34:49 PM (11 years ago)
Author:
mnot@…
Message:

sidestep 'expiration' definition; add note that expires in the past may not behave as advertised

File:
1 edited

Legend:

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

    r477 r478  
    473473        <t>HTTP caching works best when caches can entirely avoid making requests to the origin
    474474          server. When a response is "fresh" in the cache, it can be used to satisfy subsequent
    475           requests without contacting the origin server. This is also referred to as "expiration."<cref source="JRE">What exactly is called 'expiration'?</cref>.</t>
    476         <t>Expiration applies only to responses taken from a cache and not to first-hand responses.
     475          requests without contacting the origin server.</t>
     476        <t>This mechanism applies only to responses taken from a cache and not to first-hand responses.
    477477          It cannot be used to force a user agent to refresh its display or reload a resource; its
    478478          semantics apply only to caches. See <xref target="history.lists" /> for an explanation of
     
    483483            target="cache-response-directive" />). Generally, origin servers will assign future
    484484          explicit expiration times to responses in the belief that the entity is not likely to
    485           change in a semantically significant way before the expiration time is reached. This
    486           normally preserves cache correctness, as long as the server's expiration times are
    487           carefully chosen.</t>
     485          change in a semantically significant way before the expiration time is reached.</t>
    488486        <t>If an origin server wishes to force a cache to validate every request, it &MAY;
    489487          assign an explicit expiration time in the past. This means that the response is always
    490           stale, so that caches should validate it before using it for subsequent requests.</t>
     488          stale, so that caches should validate it before using it for subsequent requests. <cref>This wording may cause confusion, because the response may still be served stale.</cref></t>
    491489        <t>Since origin servers do not always provide explicit expiration times, HTTP caches may
    492490          assign heuristic expiration times when they are not specified, employing algorithms that
Note: See TracChangeset for help on using the changeset viewer.