Changeset 478 for draft-ietf-httpbis

Timestamp:

04/03/09 03:34:49 (13 years ago)

Author:

mnot@…

Message:

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

File:

• draft-ietf-httpbis/latest-roy/p6-cache.xml (modified) (2 diffs)

draft-ietf-httpbis/latest-roy/p6-cache.xml

@@ -473 +473 @@
         <t>HTTP caching works best when caches can entirely avoid making requests to the origin
           server. When a response is "fresh" in the cache, it can be used to satisfy subsequent
-          requests without contacting the origin server. This is also referred to as "expiration."<cref source="JRE">What exactly is called 'expiration'?</cref>.</t>
-        <t>Expiration applies only to responses taken from a cache and not to first-hand responses.
+          requests without contacting the origin server.</t>
+        <t>This mechanism applies only to responses taken from a cache and not to first-hand responses.
           It cannot be used to force a user agent to refresh its display or reload a resource; its
           semantics apply only to caches. See <xref target="history.lists" /> for an explanation of
@@ -483 +483 @@
             target="cache-response-directive" />). Generally, origin servers will assign future
           explicit expiration times to responses in the belief that the entity is not likely to
-          change in a semantically significant way before the expiration time is reached. This
-          normally preserves cache correctness, as long as the server's expiration times are
-          carefully chosen.</t>
+          change in a semantically significant way before the expiration time is reached.</t>
         <t>If an origin server wishes to force a cache to validate every request, it &MAY;
           assign an explicit expiration time in the past. This means that the response is always
-          stale, so that caches should validate it before using it for subsequent requests.</t>
+          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>
         <t>Since origin servers do not always provide explicit expiration times, HTTP caches may
           assign heuristic expiration times when they are not specified, employing algorithms that