Ignore:
Timestamp:
19/01/14 09:51:24 (6 years ago)
Author:
fielding@…
Message:

(editorial) remove usage of We; move definition of transforming proxy into the only section that uses it, removing the need for non-transforming proxy to be defined; clean up redundant paragraphs in description of cache-control extensions; see #531

File:
1 edited

Legend:

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

    r2554 r2563  
    451451  }
    452452  @bottom-center {
    453        content: "Expires July 21, 2014";
     453       content: "Expires July 23, 2014";
    454454  }
    455455  @bottom-right {
     
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2014-01-17">
     497      <meta name="dct.issued" scheme="ISO8601" content="2014-01-19">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    521521            </tr>
    522522            <tr>
    523                <td class="left">Expires: July 21, 2014</td>
     523               <td class="left">Expires: July 23, 2014</td>
    524524               <td class="right">J. Reschke, Editor</td>
    525525            </tr>
     
    530530            <tr>
    531531               <td class="left"></td>
    532                <td class="right">January 17, 2014</td>
     532               <td class="right">January 19, 2014</td>
    533533            </tr>
    534534         </tbody>
     
    557557            in progress”.
    558558         </p>
    559          <p>This Internet-Draft will expire on July 21, 2014.</p>
     559         <p>This Internet-Draft will expire on July 23, 2014.</p>
    560560      </div>
    561561      <div id="rfc.copyrightnotice">
     
    746746         <div id="rfc.iref.c.3"></div>
    747747         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></h1>
    748          <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when
    749             no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from
    750             either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always
    751             store and reuse particular responses.
     748         <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior
     749            when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache
     750            from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches
     751            always store and reuse particular responses.
    752752         </p>
    753753         <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common
     
    14581458               <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></h3>
    14591459               <p id="rfc.section.5.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional
    1460                   value.
     1460                  value. A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives.
    14611461               </p>
    14621462               <p id="rfc.section.5.2.3.p.2">Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics
    1463                   of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives.
    1464                </p>
    1465                <p id="rfc.section.5.2.3.p.3">Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive
    1466                   will default to the behavior specified by the standard directive, and those that understand the new directive will recognize
    1467                   it as modifying the requirements associated with the standard directive. In this way, extensions to the cache-control directives
    1468                   can be made without requiring changes to the base protocol.
    1469                </p>
    1470                <p id="rfc.section.5.2.3.p.4">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
    1471                   obeying certain extensions, and ignoring all directives that it does not understand.
    1472                </p>
    1473                <p id="rfc.section.5.2.3.p.5">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
    1474                   We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the
    1475                   community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to
    1476                   use an otherwise private response in their shared cache(s) could do so by including
     1463                  of other directives.
     1464               </p>
     1465               <p id="rfc.section.5.2.3.p.3">Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive
     1466                  and the old directive are supplied, such that applications that do not understand the new directive will default to the behavior
     1467                  specified by the old directive, and those that understand the new directive will recognize it as modifying the requirements
     1468                  associated with the old directive. In this way, extensions to the existing cache-control directives can be made without breaking
     1469                  deployed caches.
     1470               </p>
     1471               <p id="rfc.section.5.2.3.p.4">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive:
     1472                  in addition to private caches, any cache that is shared only by members of the named community is allowed to cache the response.
     1473                  An origin server wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do
     1474                  so by including
    14771475               </p>
    14781476               <div id="rfc.figure.u.8"></div><pre class="text">  Cache-Control: private, community="UCI"
    1479 </pre><p id="rfc.section.5.2.3.p.7">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
    1480                   it will also see and understand the private directive and thus default to the safe behavior.
    1481                </p>
    1482                <p id="rfc.section.5.2.3.p.8">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache
    1483                   will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain
    1484                   minimally correct even if the cache does not understand the extension(s).
     1477</pre><p id="rfc.section.5.2.3.p.6">A cache that recognizes such a community cache-extension could broaden its behavior in accordance with that extension. A cache
     1478                  that does not recognize the community cache-extension would ignore it and adhere to the private directive.
    14851479               </p>
    14861480            </div>
Note: See TracChangeset for help on using the changeset viewer.