Changeset 181 for draft-ietf-httpbis/latest/p6-cache.html

Timestamp:

Feb 1, 2008, 1:55:09 PM (12 years ago)

Author:

fielding@…

Message:

editorial: tweak intro to be more direct without former/latter backrefs
and irrelevant details.
Replace typo "resource is cacheable" with "response is cacheable"

File:

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

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

@@ -585 +585 @@
          Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
       </p>
-      <p id="rfc.section.1.1.p.2">Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate
-         the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former
-         reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose
-         (see <a href="#expiration.model" title="Expiration Model">Section&nbsp;3</a>). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see <a href="#validation.model" title="Validation Model">Section&nbsp;4</a>).
+      <p id="rfc.section.1.1.p.2">Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to reuse a prior
+         response message to satisfy a current request. In some cases, the existing response can be reused without the need for a network
+         request, reducing latency and network round-trips; we use an "expiration" mechanism for this purpose (see <a href="#expiration.model" title="Expiration Model">Section&nbsp;3</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy
+         the request, thereby reducing network bandwidth usage; we use a "validation" mechanism for this purpose (see <a href="#validation.model" title="Validation Model">Section&nbsp;4</a>).
       </p>
       <div id="rfc.iref.s.1"></div>
       <p id="rfc.section.1.1.p.3">A cache behaves in a "<dfn>semantically transparent</dfn>" manner, with respect to a particular response, when its use affects neither the requesting client nor the origin server,
-         except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except
-         for hop-by-hop headers) that it would have received had its request been handled directly by the origin server.
+         except to improve performance. When a cache is semantically transparent, the client receives exactly the same response status
+         and payload that it would have received had its request been handled directly by the origin server.
       </p>
       <p id="rfc.section.1.1.p.4">In an ideal world, all interactions with an HTTP cache would be semantically transparent. However, for some resources, semantic
@@ -626 +626 @@
       <dl class="empty">
          <dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
-            Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular
+            Even when a response is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular
             request.
          </dd>