Changeset 181


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"

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r173 r181  
    237237<t>
    238238   Caching would be useless if it did not significantly improve
    239    performance. The goal of caching in HTTP/1.1 is to eliminate the need
    240    to send requests in many cases, and to eliminate the need to send
    241    full responses in many other cases. The former reduces the number of
    242    network round-trips required for many operations; we use an
    243    "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The
    244    latter reduces network bandwidth requirements; we use a "validation"
    245    mechanism for this purpose (see <xref target="validation.model"/>).
     239   performance. The goal of caching in HTTP/1.1 is to reuse a prior response
     240   message to satisfy a current request.  In some cases, the existing response
     241   can be reused without the need for a network request, reducing latency and
     242   network round-trips; we use an "expiration" mechanism for this purpose
     243   (see <xref target="expiration.model"/>).  Even when a new request is required,
     244   it is often possible to reuse all or parts of the payload of a prior response
     245   to satisfy the request, thereby reducing network bandwidth usage; we use a
     246   "validation" mechanism for this purpose (see <xref target="validation.model"/>).
    246247</t>
    247248<iref item="semantically transparent"/>
     
    251252   requesting client nor the origin server, except to improve
    252253   performance. When a cache is semantically transparent, the client
    253    receives exactly the same response (except for hop-by-hop headers)
     254   receives exactly the same response status and payload
    254255   that it would have received had its request been handled directly
    255256   by the origin server.
     
    314315      A response is cacheable if a cache is allowed to store a copy of
    315316      the response message for use in answering subsequent requests.
    316       Even if a resource is cacheable, there may
     317      Even when a response is cacheable, there may
    317318      be additional constraints on whether a cache can use the cached
    318319      copy for a particular request.
Note: See TracChangeset for help on using the changeset viewer.