Changeset 181 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 01/02/08 21:55:09 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r173 r181 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. 586 586 </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 eliminate588 the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former589 re duces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose590 (see <a href="#expiration.model" title="Expiration Model">Section 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 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 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 4</a>). 591 591 </p> 592 592 <div id="rfc.iref.s.1"></div> 593 593 <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 (except595 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. 596 596 </p> 597 597 <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"> 627 627 <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 particular628 Even when a response is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular 629 629 request. 630 630 </dd>
Note: See TracChangeset
for help on using the changeset viewer.