Ignore:
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:
1 edited

Legend:

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

    r173 r181  
    585585         Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
    586586      </p>
    587       <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
    588          the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former
    589          reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose
    590          (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>).
     587      <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
     588         response message to satisfy a current request. In some cases, the existing response can be reused without the need for a network
     589         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
     590         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>).
    591591      </p>
    592592      <div id="rfc.iref.s.1"></div>
    593593      <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,
    594          except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except
    595          for hop-by-hop headers) that it would have received had its request been handled directly by the origin server.
     594         except to improve performance. When a cache is semantically transparent, the client receives exactly the same response status
     595         and payload that it would have received had its request been handled directly by the origin server.
    596596      </p>
    597597      <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
     
    626626      <dl class="empty">
    627627         <dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    628             Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular
     628            Even when a response is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular
    629629            request.
    630630         </dd>
Note: See TracChangeset for help on using the changeset viewer.