Ignore:
Timestamp:
Jan 7, 2008, 7:19:58 PM (12 years ago)
Author:
fielding@…
Message:

editorial: Move caching intro in overview to introduction along
with the prerequisite definitions. Move definition of delta-seconds
to where it is first used (Age). Add a couple glue sentences.
Replace redundant "the HTTP/1.1 protocol" with "HTTP/1.1".

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r154 r157  
    215215</front>
    216216<middle>
    217 <section title="Introduction" anchor="introduction">
    218 <t>
    219    This document will define aspects of HTTP related to caching response
    220    messages.  Right now it only includes the extracted relevant sections
    221    of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> without edit.
    222 </t>
    223 
    224 <section title="Requirements" anchor="intro.requirements">
    225 <t>
    226    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    227    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    228    document are to be interpreted as described in <xref target="RFC2119"/>.
    229 </t>
    230 <t>
    231    An implementation is not compliant if it fails to satisfy one or more
    232    of the &MUST; or &REQUIRED; level requirements for the protocols it
    233    implements. An implementation that satisfies all the &MUST; or &REQUIRED;
    234    level and all the &SHOULD; level requirements for its protocols is said
    235    to be "unconditionally compliant"; one that satisfies all the &MUST;
    236    level requirements but not all the &SHOULD; level requirements for its
    237    protocols is said to be "conditionally compliant."
     217<section title="Introduction" anchor="caching">
     218<t>
     219   HTTP is typically used for distributed information systems, where
     220   performance can be improved by the use of response caches. The
     221   HTTP/1.1 protocol includes a number of elements intended to make
     222   caching work as well as possible. Because these elements are
     223   inextricable from other aspects of the protocol, and because they
     224   interact with each other, it is useful to describe the basic caching
     225   design of HTTP separately from the detailed descriptions of methods,
     226   headers, response codes, etc.  This document defines aspects of HTTP
     227   related to caching response messages.
     228</t>
     229
     230<section title="Purpose" anchor="intro.purpose">
     231<iref item="cache"/>
     232<t>
     233   An HTTP <x:dfn>cache</x:dfn> is a local store of response messages
     234   and the subsystem that controls its message storage, retrieval, and
     235   deletion. A cache stores cacheable responses in order to reduce the
     236   response time and network bandwidth consumption on future, equivalent
     237   requests. Any client or server may include a cache, though a cache
     238   cannot be used by a server that is acting as a tunnel.
     239</t>
     240<t>
     241   Caching would be useless if it did not significantly improve
     242   performance. The goal of caching in HTTP/1.1 is to eliminate the need
     243   to send requests in many cases, and to eliminate the need to send
     244   full responses in many other cases. The former reduces the number of
     245   network round-trips required for many operations; we use an
     246   "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The
     247   latter reduces network bandwidth requirements; we use a "validation"
     248   mechanism for this purpose (see <xref target="validation.model"/>).
     249</t>
     250<iref item="semantically transparent"/>
     251<t>
     252   A cache behaves in a "<x:dfn>semantically transparent</x:dfn>" manner, with
     253   respect to a particular response, when its use affects neither the
     254   requesting client nor the origin server, except to improve
     255   performance. When a cache is semantically transparent, the client
     256   receives exactly the same response (except for hop-by-hop headers)
     257   that it would have received had its request been handled directly
     258   by the origin server.
     259</t>
     260<t>
     261   In an ideal world, all interactions with an HTTP cache would be
     262   semantically transparent.  However, for some resources, semantic
     263   transparency is not always necessary and can be effectively traded
     264   for the sake of bandwidth scaling, disconnected operation, and
     265   high availability.  HTTP/1.1 allows origin servers, caches,
     266   and clients to explicitly reduce transparency when necessary.
     267   However, because non-transparent operation may confuse non-expert
     268   users and might be incompatible with certain server applications
     269   (such as those for ordering merchandise), the protocol requires that
     270   transparency be relaxed
     271  <list style="symbols">
     272     <t>only by an explicit protocol-level request when relaxed by
     273        client or origin server</t>
     274
     275     <t>only with an explicit warning to the end user when relaxed by
     276        cache or client</t>
     277  </list>
     278</t>
     279<t>
     280   Therefore, HTTP/1.1 provides these important elements:
     281  <list style="numbers">
     282      <t>Protocol features that provide full semantic transparency when
     283         this is required by all parties.</t>
     284
     285      <t>Protocol features that allow an origin server or user agent to
     286         explicitly request and control non-transparent operation.</t>
     287
     288      <t>Protocol features that allow a cache to attach warnings to
     289         responses that do not preserve the requested approximation of
     290         semantic transparency.</t>
     291  </list>
     292</t>
     293<t>
     294   A basic principle is that it must be possible for the clients to
     295   detect any potential relaxation of semantic transparency.
     296  <list><t>
     297      <x:h>Note:</x:h> The server, cache, or client implementor might be faced with
     298      design decisions not explicitly discussed in this specification.
     299      If a decision might affect semantic transparency, the implementor
     300      ought to err on the side of maintaining transparency unless a
     301      careful and complete analysis shows significant benefits in
     302      breaking transparency.
     303    </t></list>
    238304</t>
    239305</section>
    … …  
    242308<t>
    243309   This specification uses a number of terms to refer to the roles
    244    played by participants in, and objects of, the HTTP communication.
    245 </t>
    246 <t>
    247   <iref item="cache"/>
    248   <x:dfn>cache</x:dfn>
    249   <list>
    250     <t>
    251       A program's local store of response messages and the subsystem
    252       that controls its message storage, retrieval, and deletion. A
    253       cache stores cacheable responses in order to reduce the response
    254       time and network bandwidth consumption on future, equivalent
    255       requests. Any client or server may include a cache, though a cache
    256       cannot be used by a server that is acting as a tunnel.
    257     </t>
    258   </list>
     310   played by participants in, and objects of, HTTP caching.
    259311</t>
    260312<t>
    … …  
    264316    <t>
    265317      A response is cacheable if a cache is allowed to store a copy of
    266       the response message for use in answering subsequent requests. The
    267       rules for determining the cacheability of HTTP responses are
    268       defined in <xref target="caching"/>. Even if a resource is cacheable, there may
     318      the response message for use in answering subsequent requests.
     319      Even if a resource is cacheable, there may
    269320      be additional constraints on whether a cache can use the cached
    270321      copy for a particular request.
    … …  
    344395</t>
    345396<t>
    346   <iref item="semantically transparent"/>
    347   <x:dfn>semantically transparent</x:dfn>
    348   <list>
    349     <t>
    350       A cache behaves in a "semantically transparent" manner, with
    351       respect to a particular response, when its use affects neither the
    352       requesting client nor the origin server, except to improve
    353       performance. When a cache is semantically transparent, the client
    354       receives exactly the same response (except for hop-by-hop headers)
    355       that it would have received had its request been handled directly
    356       by the origin server.
    357     </t>
    358   </list>
    359 </t>
    360 <t>
    361397  <iref item="validator"/>
    362398  <x:dfn>validator</x:dfn>
    … …  
    371407</section>
    372408
    373 <section title="Delta Seconds" anchor="delta.seconds">
    374 <t>
    375    Some HTTP header fields allow a time value to be specified as an
    376    integer number of seconds, represented in decimal, after the time
    377    that the message was received.
    378 </t>
    379 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/>
    380   delta-seconds  = 1*DIGIT
    381 </artwork></figure>
    382 </section>
    383 </section>
    384 
    385 <section title="Caching in HTTP" anchor="caching">
     409<section title="Requirements" anchor="intro.requirements">
     410<t>
     411   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     412   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     413   document are to be interpreted as described in <xref target="RFC2119"/>.
     414</t>
     415<t>
     416   An implementation is not compliant if it fails to satisfy one or more
     417   of the &MUST; or &REQUIRED; level requirements for the protocols it
     418   implements. An implementation that satisfies all the &MUST; or &REQUIRED;
     419   level and all the &SHOULD; level requirements for its protocols is said
     420   to be "unconditionally compliant"; one that satisfies all the &MUST;
     421   level requirements but not all the &SHOULD; level requirements for its
     422   protocols is said to be "conditionally compliant."
     423</t>
     424</section>
     425</section>
     426
    386427<section title="Overview" anchor="caching.overview">
    387 <t>
    388    HTTP is typically used for distributed information systems, where
    389    performance can be improved by the use of response caches. The
    390    HTTP/1.1 protocol includes a number of elements intended to make
    391    caching work as well as possible. Because these elements are
    392    inextricable from other aspects of the protocol, and because they
    393    interact with each other, it is useful to describe the basic caching
    394    design of HTTP separately from the detailed descriptions of methods,
    395    headers, response codes, etc.
    396 </t>
    397 <t>
    398    Caching would be useless if it did not significantly improve
    399    performance. The goal of caching in HTTP/1.1 is to eliminate the need
    400    to send requests in many cases, and to eliminate the need to send
    401    full responses in many other cases. The former reduces the number of
    402    network round-trips required for many operations; we use an
    403    "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The
    404    latter reduces network bandwidth requirements; we use a "validation"
    405    mechanism for this purpose (see <xref target="validation.model"/>).
    406 </t>
    407 <t>
    408    Requirements for performance, availability, and disconnected
    409    operation require us to be able to relax the goal of semantic
    410    transparency. The HTTP/1.1 protocol allows origin servers, caches,
    411    and clients to explicitly reduce transparency when necessary.
    412    However, because non-transparent operation may confuse non-expert
    413    users, and might be incompatible with certain server applications
    414    (such as those for ordering merchandise), the protocol requires that
    415    transparency be relaxed
    416   <list style="symbols">
    417      <t>only by an explicit protocol-level request when relaxed by
    418         client or origin server</t>
    419 
    420      <t>only with an explicit warning to the end user when relaxed by
    421         cache or client</t>
    422   </list>
    423 </t>
    424 <t>
    425    Therefore, the HTTP/1.1 protocol provides these important elements:
    426   <list style="numbers">
    427       <t>Protocol features that provide full semantic transparency when
    428          this is required by all parties.</t>
    429 
    430       <t>Protocol features that allow an origin server or user agent to
    431          explicitly request and control non-transparent operation.</t>
    432 
    433       <t>Protocol features that allow a cache to attach warnings to
    434          responses that do not preserve the requested approximation of
    435          semantic transparency.</t>
    436   </list>
    437 </t>
    438 <t>
    439    A basic principle is that it must be possible for the clients to
    440    detect any potential relaxation of semantic transparency.
    441   <list><t>
    442       <x:h>Note:</x:h> The server, cache, or client implementor might be faced with
    443       design decisions not explicitly discussed in this specification.
    444       If a decision might affect semantic transparency, the implementor
    445       ought to err on the side of maintaining transparency unless a
    446       careful and complete analysis shows significant benefits in
    447       breaking transparency.
    448     </t></list>
    449 </t>
    450 
    451428<section title="Cache Correctness" anchor="cache.correctness">
    452429<t>
    … …  
    15321509</t>
    15331510</section>
    1534 </section>
    15351511
    15361512<section title="Header Field Definitions" anchor="header.fields">
    … …  
    15621538      seconds.
    15631539</t>
     1540<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/>
     1541  delta-seconds  = 1*DIGIT
     1542</artwork></figure>
    15641543<t>
    15651544      If a cache receives a value larger than the largest positive
Note: See TracChangeset for help on using the changeset viewer.