Changeset 411


Ignore:
Timestamp:
15/11/08 21:44:37 (14 years ago)
Author:
mnot@…
Message:

more updates.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r394 r411  
    226226          (see <xref target="expiration.model" />). Even when a new request is required, it is often
    227227          possible to reuse all or parts of the payload of a prior response to satisfy the request,
    228           thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose
    229           (see <xref target="validation.model" />).</t>
     228          thereby reducing network bandwidth usage; a "validation" mechanism is used for this
     229          purpose (see <xref target="validation.model" />).</t>
    230230      </section>
    231231
    … …  
    244244        </t>
    245245        <t>
    246           <iref item="first-hand" />
    247           <x:dfn>first-hand</x:dfn>
    248           <list>
    249             <t>A response is first-hand if it comes from the origin server, perhaps via one or more
    250               proxies, but not from cache. A response is also first-hand if its validity has just
    251               been checked directly with the origin server.</t>
    252           </list>
    253         </t>
    254         <t>
    255246          <iref item="explicit expiration time" />
    256247          <x:dfn>explicit expiration time</x:dfn>
    … …  
    274265            <t>The age of a response is the time since it was sent by, or successfully validated
    275266              with, the origin server.</t>
     267          </list>
     268        </t>
     269        <t>
     270          <iref item="first-hand" />
     271          <x:dfn>first-hand</x:dfn>
     272          <list>
     273            <t>A response is first-hand if the freshness model is not in use; i.e., its age is
     274            0.</t>
    276275          </list>
    277276        </t>
    … …  
    374373    <section anchor="caching.overview" title="Cache Operation">
    375374
    376       <section anchor="cache.correctness" title="Cache Correctness">
    377         <iref item="cache.correctness" />
    378         <t>When a cache is "<x:dfn>correct</x:dfn>", the client receives exactly the same response
    379           status and payload that it would have received had its request been handled directly by
    380           the origin server.</t>
    381         <t>Ideally, all interactions with an HTTP cache would be correct. However, for some
    382           resources, complete correctness is not always necessary and can be effectively traded for
    383           the sake of bandwidth scaling, disconnected operation, and high availability. HTTP/1.1
    384           allows origin servers, caches, and clients to explicitly reduce correctness when
    385           necessary.</t>
    386         <t>However, because incorrect operation may confuse users and might be incompatible with
    387           server applications (such as those for ordering merchandise), caches MUST NOT relax
    388           correctness unless: <list style="symbols">
    389             <t>the client or origin server permits it with an explicit protocol-level element; see
    390                 <xref target="header.cache-control" />, or</t>
    391             <t>the cache provides an explicit warning to the end user; see <xref
    392                 target="header.warning" />.</t>
    393           </list>
    394         </t>
    395         <t>
    396           <cref>REVIEW: previous semantic transparency text didn't make a lot of sense; replacing
    397             with "correctness"</cref>
    398         </t>
    399         <t>
    400           <cref>TODO: align with intermediary semantic transparency in p1</cref>
    401         </t>
    402         <t>
    403           <cref>REVIEW: removed Explicit User Agent Warnings section</cref>
    404         </t>
    405       </section>
    406 
    407375      <section anchor="response.cacheability" title="Response Cacheability">
    408         <t>A cache MAY store a response to any request, provided that: <list style="symbols">
    409             <t>the "no-store" cache-control directive (see <xref target="header.cache-control" />)
    410               does not appear in request or response headers.</t>
     376        <t>A cache &MAY; store a response to any request, provided that: <list style="symbols">
     377            <t>the "no-store" cache directive (see <xref target="header.cache-control" />) does not
     378              appear in request or response headers.</t>
    411379            <t>the cache understands partial responses, if the response is partial or incomplete
    412380              (see <xref target="errors.or.incomplete.response.cache.behavior" />).</t>
    … …  
    416384          cache validator nor an explicitly expiration time, as such responses are not usually
    417385          useful to store. However, caches are not prohibited from storing such responses.</t>
     386
     387        <section anchor="errors.or.incomplete.response.cache.behavior"
     388          title="Storing Incomplete Responses">
     389          <t>A cache that receives an incomplete response (for example, with fewer bytes of data
     390            than specified in a Content-Length header) &MAY; store the response. However, the
     391            cache &MUST; treat this as a partial response &partial;. Partial responses
     392            &MAY; be combined as described in &combining-byte-ranges;; the result might be a
     393            full response or might still be partial. A cache &MUST-NOT; return a partial
     394            response to a client without explicitly marking it as such using the 206 (Partial
     395            Content) status code.</t>
     396          <t>A cache that does not support the Range and Content-Range headers &MUST-NOT; store
     397            incomplete or partial responses.</t>
     398        </section>
     399
    418400      </section>
    419401
    … …  
    434416        </t>
    435417        <t>
    436           <cref>ISSUE: This doesn't specify whether the request method is part of the cache key.</cref>
     418          <cref>ISSUE: This doesn't specify whether the request method is part of the cache
     419          key.</cref>
    437420        </t>
    438421        <t>A shared cache &MAY; return a stored response, provided that: <list style="symbols">
    … …  
    444427          </list>
    445428        </t>
     429        <t>All responses satisfied from cache &MUST; include an appropriate Age header field
     430            (<xref target="header.age" />).</t>
    446431        <t>All request methods other than GET and HEAD &MUST; be written through the cache to
    447432          the origin server. Note that such requests might invalidate already stored responses; see
    … …  
    453438        <t>In the process of determining whether a stored response is fresh or not, a cache
    454439          &MAY; validate that response (see <xref target="validation.model" />).</t>
     440        <t>
     441          <cref>TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in
     442            p1</cref>
     443        </t>
    455444      </section>
    456445
    … …  
    469458        <t>The primary mechanism for avoiding requests is for an origin server to provide an
    470459          explicit expiration time in the future, using either the Expires header <xref
    471             target="header.expires" /> or the max-age directive of the Cache-Control header <xref
    472             target="header.cache-control" />. Generally, origin servers will assign future explicit
    473           expiration times to responses in the belief that the entity is not likely to change in a
    474           semantically significant way before the expiration time is reached. This normally
    475           preserves cache correctness, as long as the server's expiration times are carefully
    476           chosen.</t>
     460            target="header.expires" /> or the max-age response cache directive <xref
     461            target="cache-response-directive" />. Generally, origin servers will assign future
     462          explicit expiration times to responses in the belief that the entity is not likely to
     463          change in a semantically significant way before the expiration time is reached. This
     464          normally preserves cache correctness, as long as the server's expiration times are
     465          carefully chosen.</t>
    477466        <t>If an origin server wishes to force a cache to validate every request, it &MAY;
    478467          assign an explicit expiration time in the past. This means that the response is always
    479           stale, and so the cache &SHOULD; validate it before using it for subsequent requests.</t>
     468          stale, so that caches should validate it before using it for subsequent requests.</t>
    480469        <t>Since origin servers do not always provide explicit expiration times, HTTP caches may
    481470          assign heuristic expiration times when they are not specified, employing algorithms that
    … …  
    483472          expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does
    484473          impose worst-case constraints on their results.</t>
    485         <t>Additionally, in some cases the client might need to influence freshness calculation.
    486           Clients can do this using several directives of the Cache-Control header, with the effect
    487           of either increasing or loosening constraints on freshness.</t>
    488 
    489474        <t>The calculation to determine if a response has expired is:</t>
    490475        <figure>
    … …  
    496481        <t>The freshness_lifetime is defined in <xref target="calculating.freshness.lifetime" />;
    497482          the current_age is defined in <xref target="age.calculations" />.</t>
    498 
     483        <t>Additionally, clients may need to influence freshness calculation. They can do this using
     484          several request cache directives, with the effect of either increasing or loosening
     485          constraints on freshness. See <xref target="cache-request-directive" />.</t>
    499486        <t>
    500           <cref>TODO: incorporate client-specified freshness controls.</cref>
    501         </t>
    502         <t>
    503           <cref>TODO: incorporate s-maxage</cref>
    504         </t>
    505 
     487          <cref>ISSUE: there are not requirements directly applying to cache-request-directives and
     488            freshness.</cref>
     489        </t>
    506490
    507491        <section anchor="calculating.freshness.lifetime" title="Calculating Freshness Lifetime">
    508           <t>"expires_value" denotes the value of the Expires header <xref target="header.expires"
    509              />. "max_age_value" denotes the number of seconds carried by the "max-age" directive of
    510             the Cache-Control header in a response (see <xref target="header.cache-control" />).</t>
    511           <t>The max-age directive takes priority over Expires, so if max-age is present in a
    512             response, the calculation:</t>
    513           <figure>
    514             <artwork type="code">
    515    freshness_lifetime = max_age_value
    516 </artwork>
    517           </figure>
    518           <t>Otherwise, if Expires is present in the response, the calculation is:</t>
    519           <figure>
    520             <artwork type="code">
    521    freshness_lifetime = expires_value - date_value
    522 </artwork>
    523           </figure>
    524           <t>Note that the calculations above are not vulnerable to clock skew, since all of the
     492          <t>A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a
     493            response by using the first match of: <list style="symbols">
     494              <t>If the cache is shared and the s-maxage response cache directive (<xref
     495                  target="cache-response-directive" />) is present, use its value, or</t>
     496              <t>If the max-age response cache directive (<xref target="cache-response-directive"
     497                 />) is present, use its value, or</t>
     498              <t>If the Expires response header (<xref target="header.expires" />) is present, use
     499                its value minus the value of the Date response header, or</t>
     500              <t>Otherwise, no explicit expiration time is present in the response, but a heuristic
     501                may be used; see <xref target="heuristic.freshness" />.</t>
     502            </list>
     503          </t>
     504          <t>Note that this calculation is not vulnerable to clock skew, since all of the
    525505            information comes from the origin server.</t>
    526         </section>
    527 
    528         <section anchor="heuristic.freshness" title="Heuristic Freshness">
    529           <t>If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage appears in the
    530             response, and the response does not include other restrictions on caching, the cache
    531             &MAY; compute a freshness_lifetime using a heuristic, if the stored response's
    532             status code is one of 200, 203, 206, 300, 301 or 410. Heuristics &MUST-NOT; be used
    533             for other response status codes. When a heuristic is used to calculate
    534             freshness_lifetime, the cache &MUST; attach a Warning header with a 113 warn-code to the response if its
    535             current_age is more than 24 hours and such a warning is not already present.</t>
    536           <t>Also, if the response has a Last-Modified header &header-last-modified;, the
    537             heuristic expiration value &SHOULD; be no more than some fraction of the interval
    538             since that time. A typical setting of this fraction might be 10%.</t>
    539           <t>
    540             <cref>REVIEW: took away HTTP/1.0 query string heuristic uncacheability.</cref>
    541           </t>
     506
     507          <section anchor="heuristic.freshness" title="Using Heuristic Freshness">
     508            <t>If no explicit expiration time is present in a stored response that has a status code
     509              of 200, 203, 206, 300, 301 or 410, a heuristic expiration time &MAY; be
     510              calculated. Heuristics &MUST-NOT; be used for other response status codes. </t>
     511            <t> When a heuristic is used to calculate freshness lifetime, the cache &SHOULD;
     512              attach a Warning header with a 113 warn-code to the response if its current_age is
     513              more than 24 hours and such a warning is not already present.</t>
     514            <t>Also, if the response has a Last-Modified header &header-last-modified;, the
     515              heuristic expiration value &SHOULD; be no more than some fraction of the interval
     516              since that time. A typical setting of this fraction might be 10%.</t>
     517            <t>
     518              <cref>REVIEW: took away HTTP/1.0 query string heuristic uncacheability.</cref>
     519            </t>
     520          </section>
    542521        </section>
    543522
    … …  
    549528            each of the caches along the path from the origin server, plus the amount of time it has
    550529            been in transit along network paths.</t>
    551           <t>When a response is generated from a stored response, the cache &MUST; include a single
    552             Age header field in the response with a value equal to the stored response's current_age,
    553             calculated using the algorithm described in this section.</t>
     530          <t>When a response is generated from a stored response, the cache &MUST; include a
     531            single Age header field in the response with a value equal to the stored response's
     532            current_age, calculated using the algorithm described in this section.</t>
    554533          <t>The term "age_value" denotes the value of the Age header, in a form appropriate for
    555534            arithmetic operations.</t>
    … …  
    576555</artwork>
    577556          </figure>
    578           <t>When an Age value is
    579             received, it &MUST; be interpreted relative to the time the request was initiated,
    580             not the time that the response was received.</t>
     557          <t>When an Age value is received, it &MUST; be interpreted relative to the time the
     558            request was initiated, not the time that the response was received.</t>
    581559          <figure>
    582560            <artwork type="code">
    … …  
    587565          <t>where "request_time" is the time (according to the local clock) when the request that
    588566            elicited this response was sent.</t>
    589           <t>The current_age of a stored response can then be calculated by adding the amount of time
    590             (in seconds) since the stored response was last validated by the origin server to the
    591             corrected_initial_age.</t>
     567          <t>The current_age of a stored response can then be calculated by adding the amount of
     568            time (in seconds) since the stored response was last validated by the origin server to
     569            the corrected_initial_age.</t>
    592570          <t>In summary:</t>
    593571          <figure>
    … …  
    619597        </section>
    620598
    621 
    622599        <section anchor="serving.stale.responses" title="Serving Stale Responses">
    623           <t>Caches &MAY; return a stale response, unless such a response is otherwise prohibited
    624             (e.g., by a "no-store" or "no-cache" cache-request-directive, or a "must-revalidate"
    625             cache-response-directive; see <xref target="header.cache-control" />). Such stale responses
    626             MUST have a Warning header with the 110 warn-code (see <xref format="counter"
    627               target="header.warning" />)</t>
    628           <t>A stale response &MUST; have freshness information available, either explicitly or
    629             heuristically. See <xref target="calculating.freshness.lifetime" /></t>
     600          <t>A "stale" response is one that either has explicit expiry information, or is allowed to
     601            have heuristic expiry calculated, but is not fresh according to the calculations in
     602              <xref target="expiration.model" />. </t>
     603          <t>Caches &MUST-NOT; return a stale response if it is prohibited by an explicit
     604            in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a
     605            "must-revalidate" cache-response-directive, or an applicable "s-maxage" or
     606            "proxy-revalidate" cache-response-directive; see <xref target="cache-response-directive"
     607             />). </t>
     608          <t>Caches &MAY; return a stale response if disconnected or explicitly allowed (e.g.,
     609            the max-stale request directive; see <xref target="cache-request-directive" />).</t>
     610          <t>Otherwise, caches &SHOULD-NOT; return stale responses.</t>
     611          <t>Stale responses &SHOULD; have a Warning header with the 110 warn-code (see <xref
     612              format="counter" target="header.warning" />).</t>
    630613          <t>If a cache receives a first-hand response (either an entire response, or a 304 (Not
    631614            Modified) response) that it would normally forward to the requesting client, and the
    632             received response is no longer fresh, the cache &SHOULD; forward it to the requesting
    633             client without adding a new Warning (but without removing any existing Warning headers). A
    634             cache &SHOULD-NOT; attempt to validate a response simply because that response
    635             became stale in transit.</t>
    636         </section>   
    637 
     615            received response is no longer fresh, the cache &SHOULD; forward it to the
     616            requesting client without adding a new Warning (but without removing any existing
     617            Warning headers). A cache &SHOULD-NOT; attempt to validate a response simply because
     618            that response became stale in transit.</t>
     619        </section>
    638620      </section>
    639621
    640622
    641623      <section anchor="validation.model" title="Validation Model">
    642         <t>When a cache has a stale response that it would like to use, it should first check with
    643           the origin server (or possibly an intermediate cache with a fresh response) to see if it
    644           is still usable. This is called "validating" or "revalidating" the stored response.</t>
     624        <t>When a cache has a stale response that it would like to use, it &SHOULD; first check
     625          with the origin server (or possibly an intermediate cache with a fresh response) to see if
     626          it is still usable. This is called "validating" or "revalidating" the stored response.</t>
    645627        <t>HTTP's conditional request mechanism, defined in &conditional;, is used to avoid
    646           retransmitting the response payload when the stored response is valid. When a stored response
    647           includes one or more "cache validators," such as the field values of an ETag or
     628          retransmitting the response payload when the stored response is valid. When a stored
     629          response includes one or more "cache validators," such as the field values of an ETag or
    648630          Last-Modified header field, then a validating GET request &SHOULD; be made conditional
    649631          to those field values. The server checks the conditional request's validator against the
    … …  
    654636          including payload, so that the request can be satisfied and the stored response supplanted
    655637          without the need for an additional network round-trip.</t>
    656         <t>See <xref target="combining.headers" /> for information about combining cached headers
    657           with those in a 304 response.</t>
     638        <t>See <xref target="combining.headers" /> regarding combining cached headers with those in
     639          a 304 response.</t>
    658640        <t>If a cache receives a 5xx response while attempting to validate a response, it &MAY;
    659641          either forward this response to the requesting client, or act as if the server failed to
    660642          respond. In the latter case, it &MAY; return a previously received response unless the
    661           stored response includes the "must-revalidate" cache-control directive (see <xref
    662             target="header.cache-control" />).</t>
    663         <t>
    664           <cref>TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in
    665             p1</cref>
    666         </t>
    667       </section>
    668 
    669            
    670       <section anchor="invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">
     643          stored response includes the "must-revalidate" cache directive (see <xref
     644            target="cache-response-directive" />).</t>
     645      </section>
     646
     647      <section anchor="invalidation.after.updates.or.deletions"
     648        title="Request Methods that Invalidate">
    671649        <t>Because unsafe methods &safe-methods; have the potential for changing state on the
    672650          origin server, intervening caches have the opportunity to use them to keep their contents
    … …  
    688666          invalidate the Request-URI.</t>
    689667        <t>Here, "invalidate" means that the cache will either remove all stored responses related
    690           to the Request-URI, or will mark these as "invalid" and in need of a mandatory
    691           validation before they can be returned in response to a subsequent request.</t>
     668          to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation
     669          before they can be returned in response to a subsequent request.</t>
    692670        <t>Note that this does not guarantee that all appropriate responses are invalidated. For
    693671          example, the request that caused the change at the origin server might not have gone
    … …  
    697675        </t>
    698676      </section>
    699      
    700      
     677
     678
     679
     680
     681
    701682      <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
    702683        <t>Use of server-driven content negotiation (&server-driven-negotiation;), as indicated
    … …  
    733714          unless the request is for a range that would be fully satisfied by that stored response.</t>
    734715        <t>If a cache receives a successful response whose Content-Location field matches that of an
    735           existing stored response for the same Request-URI, whose entity-tag differs from that of the
    736           existing stored response, and whose Date is more recent than that of the existing response,
    737           the existing response &SHOULD-NOT; be returned in response to future requests and
    738           &SHOULD; be deleted from the cache.</t>
     716          existing stored response for the same Request-URI, whose entity-tag differs from that of
     717          the existing stored response, and whose Date is more recent than that of the existing
     718          response, the existing response &SHOULD-NOT; be returned in response to future
     719          requests and &SHOULD; be deleted from the cache.</t>
    739720        <t>
    740           <cref>TODO: this is still really messed up.</cref>
    741         </t>
    742       </section>
    743      
    744      
    745       <section anchor="errors.or.incomplete.response.cache.behavior"
    746         title="Caching Incomplete Responses">
    747         <t>A cache that receives an incomplete response (for example, with fewer bytes of data than
    748           specified in a Content-Length header) &MAY; store the response. However, the cache
    749           &MUST; treat this as a partial response &partial;. Partial responses &MAY; be
    750           combined as described in &combining-byte-ranges;; the result might be a full response
    751           or might still be partial. A cache &MUST-NOT; return a partial response to a client
    752           without explicitly marking it as such using the 206 (Partial Content) status code.</t>
    753         <t>A cache that does not support the Range and Content-Range headers &MUST-NOT; cache
    754           incomplete or partial responses.</t>
    755       </section>
    756      
    757      
     721          <cref>TODO: this still needs work.</cref>
     722        </t>
     723      </section>
     724
     725
    758726      <section anchor="combining.headers" title="Combining Responses">
    759727        <t>When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response,
    760728          it needs to update the stored response with the new one, so that the updated response can
    761729          be sent to the client.</t>
    762         <t>If the status code is 304 (Not Modified), the cache SHOULD use the stored entity-body as
     730        <t>If the status code is 304 (Not Modified), the cache &SHOULD; use the stored entity-body as
    763731          the updated entity-body. If the status code is 206 (Partial Content) and the ETag or
    764732          Last-Modified headers match exactly, the cache &MAY; combine the stored entity-body in
    765           the stored response with the updated entity-body received in the response and use the result
    766           as the updated entity-body (see &combining-byte-ranges;).</t>
     733          the stored response with the updated entity-body received in the response and use the
     734          result as the updated entity-body (see &combining-byte-ranges;).</t>
    767735        <t>The stored response headers are used for the updated response, except that <list
    768           style="symbols">
    769           <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning" />)
    770             &MUST; be deleted from the stored response and the forwarded response.</t>
    771           <t>any stored Warning headers with warn-code 2xx &MUST; be retained in the stored
    772             response and the forwarded response.</t>
    773           <t>any headers provided in the 304 or 206 response &MUST; replace the corresponding
    774             headers from the stored response.</t>
    775         </list>
     736            style="symbols">
     737            <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning" />)
     738              &MUST; be deleted from the stored response and the forwarded response.</t>
     739            <t>any stored Warning headers with warn-code 2xx &MUST; be retained in the stored
     740              response and the forwarded response.</t>
     741            <t>any headers provided in the 304 or 206 response &MUST; replace the corresponding
     742              headers from the stored response.</t>
     743          </list>
    776744        </t>
    777745        <t>A cache &MUST; also replace stored headers with corresponding headers received in the
    778746          incoming response, except for Warning headers as described immediately above. If a header
    779           field-name in the incoming response matches more than one header in the stored response, all
    780           such old headers &MUST; be replaced. it &MAY; store the combined entity-body.</t>
    781       </section>
    782              
     747          field-name in the incoming response matches more than one header in the stored response,
     748          all such old headers &MUST; be replaced. it &MAY; store the combined
     749        entity-body.</t>
     750        <t><cref>ISSUE: discuss how to handle HEAD updates</cref></t>
     751      </section>
     752
    783753    </section>
    784754
    … …  
    806776        </figure>
    807777        <t anchor="rule.delta-seconds">
    808           <x:anchor-alias value="delta-seconds" /> Age values are non-negative decimal integers,
    809           representing time in seconds.</t>
     778          <x:anchor-alias value="delta-seconds" /> Age field-values are non-negative decimal
     779          integers, representing time in seconds.</t>
    810780        <figure>
    811781          <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="delta-seconds" />
    … …  
    815785        <t>If a cache receives a value larger than the largest positive integer it can represent, or
    816786          if any of its age calculations overflows, it &MUST; transmit an Age header with a
    817           value of 2147483648 (2<x:sup>31</x:sup>). An HTTP/1.1 server that includes a cache
    818           &MUST; include an Age header field in every response generated from its own cache.
    819           Caches &SHOULD; use an arithmetic type of at least 31 bits of range.</t>
     787          field-value of 2147483648 (2<x:sup>31</x:sup>). Caches &SHOULD; use an arithmetic type
     788          of at least 31 bits of range.</t>
    820789        <t>The presence of an Age header field in a response implies that a response is not
    821790          first-hand. However, the converse is not true, since HTTP/1.0 caches may not implement the
    … …  
    841810          regardless of their significance to that application, since the directives might be
    842811          applicable to all recipients along the request/response chain. It is not possible to
    843           target a cache-directive to a specific cache.</t>
     812          target a directive to a specific cache.</t>
    844813        <figure>
    845814          <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="Cache-Control" /><iref item="Grammar" primary="true" subitem="cache-directive" /><iref item="Grammar" primary="true" subitem="cache-extension" />
    … …  
    876845            <iref item="no-cache" primary="true" subitem="Cache Directive" /> no-cache <list>
    877846              <t>The no-cache request directive indicates that a stored response &MUST-NOT; be
    878                 used to satisfy the request without successful validation on the origin server.
    879               </t>
     847                used to satisfy the request without successful validation on the origin server. </t>
    880848            </list>
    881849          </t>
    882 
    883850          <t>
    884851            <iref item="Cache Directives" primary="true" subitem="no-store" />
    … …  
    895862            </list>
    896863          </t>
    897 
    898864          <t>
    899865            <iref item="Cache Directives" primary="true" subitem="max-age" />
    900866            <iref item="max-age" primary="true" subitem="Cache Directive" /> max-age <list>
    901               <t>The no-cache request directive indicates that the client is willing to accept a
     867              <t>The max-age request directive indicates that the client is willing to accept a
    902868                response whose age is no greater than the specified time in seconds. Unless
    903869                max-stale directive is also included, the client is not willing to accept a stale
    … …  
    985951                cache, whereas the remainder of the response message &MAY; be.</t>
    986952              <t>
    987                 <cref>ISSUE: What does this really mean? Is this a good idea?</cref>
    988               </t>
    989               <t>
    990953                <x:h>Note:</x:h> This usage of the word private only controls where the response may
    991954                be stored, and cannot ensure the privacy of the message content.</t>
    992955            </list>
    993956          </t>
    994 
    995957          <t>
    996958            <iref item="Cache Directives" primary="true" subitem="no-cache" />
    997959            <iref item="no-cache" primary="true" subitem="Cache Directive" /> no-cache <list>
    998960              <t>The no-cache response directive indicates that a response &MUST-NOT; be used to
    999                 satisfy a subseqent request without successful validation on the origin server.
     961                satisfy a subsequent request without successful validation on the origin server.
    1000962                This allows an origin server to prevent caching even by caches that have been
    1001963                configured to return stale responses.</t>
    … …  
    1026988            </list>
    1027989          </t>
    1028 
    1029           <t>
    1030             <iref item="Cache Directives" primary="true" subitem="no-transform" />
    1031             <iref item="no-transform" primary="true" subitem="Cache Directive" /> no-transform <list>
    1032               <t>The no-transform response directive indicates that an intermediate cache or proxy
    1033                 &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type response
    1034                 headers, nor the response entity-body.</t>
    1035             </list>
    1036           </t>
    1037 
    1038990          <t>
    1039991            <iref item="Cache Directives" primary="true" subitem="must-revalidate" />
    1040992            <iref item="must-revalidate" primary="true" subitem="Cache Directive" /> must-revalidate <list>
    1041               <t>The must-revalidate response-directive indicates that validation is required before
    1042               the response is used by a cache to satisfy any request.</t>
    1043               <t>When the present, caches &MUST-NOT; use a stored after it becomes stale to respond to a subsequent
    1044                 request without first validating it with the origin server.</t>
     993              <t>The must-revalidate response directive indicates that validation is required before
     994                the response is used by a cache to satisfy any request.</t>
     995              <t>When the present, caches &MUST-NOT; use a stored after it becomes stale to
     996                respond to a subsequent request without first validating it with the origin server.</t>
    1045997              <t>The must-revalidate directive is necessary to support reliable operation for
    1046998                certain protocol features. In all circumstances an HTTP/1.1 cache &MUST; obey
    … …  
    10491001              <t>Servers &SHOULD; send the must-revalidate directive if and only if failure to
    10501002                validate a request on the entity could result in incorrect operation, such as a
    1051                 silently unexecuted financial transaction. Recipients &MUST-NOT; take any
    1052                 automated action that violates this directive, and &MUST-NOT; automatically
    1053                 provide an unvalidated copy of the entity if validation fails.</t>
    1054               <t>Although this is not recommended, user agents operating under severe connectivity
    1055                 constraints &MAY; violate this directive but, if so, &MUST; explicitly warn
    1056                 the user that an unvalidated response has been provided. The warning &MUST; be
    1057                 provided on each unvalidated access, and &SHOULD; require explicit user
    1058                 confirmation.</t>
    1059               <t><cref>TODO: last two paragraphs seem nonsensical.</cref></t>
     1003                silently unexecuted financial transaction.</t>
    10601004            </list>
    10611005          </t>
    1062 
    10631006          <t>
    10641007            <iref item="Cache Directives" primary="true" subitem="proxy-revalidate" />
    10651008            <iref item="proxy-revalidate" primary="true" subitem="Cache Directive" />
    10661009            proxy-revalidate <list>
    1067               <t>The proxy-revalidate directive has the same meaning as the must-revalidate
    1068                 directive, except that it does not apply to non-shared caches.</t>
     1010              <t>The proxy-revalidate response directive has the same meaning as the must-revalidate
     1011                response directive, except that it does not apply to non-shared caches.</t>
     1012            </list>
     1013          </t>
     1014          <t>
     1015            <iref item="Cache Directives" primary="true" subitem="max-age" />
     1016            <iref item="max-age" primary="true" subitem="Cache Directive" /> max-age <list>
     1017              <t>The max-age response directive indicates that response is to be considered stale
     1018                after its age is greater than the specified number of seconds.</t>
    10691019            </list>
    10701020          </t>
    … …  
    10761026                max-age directive or the Expires header. The s-maxage directive also implies the
    10771027                semantics of the proxy-revalidate response directive.</t>
     1028            </list>
     1029          </t>
     1030          <t>
     1031            <iref item="Cache Directives" primary="true" subitem="no-transform" />
     1032            <iref item="no-transform" primary="true" subitem="Cache Directive" /> no-transform <list>
     1033              <t>The no-transform response directive indicates that an intermediate cache or proxy
     1034                &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type response
     1035                headers, nor the response entity-body.</t>
    10781036            </list>
    10791037          </t>
    … …  
    11091067            understand the community cache-extension, since it will also see and understand the
    11101068            private directive and thus default to the safe behavior.</t>
    1111           <t>Unrecognized cache-directives &MUST; be ignored; it is assumed that any
    1112             cache-directive likely to be unrecognized by an HTTP/1.1 cache will be combined with
    1113             standard directives (or the response's default cacheability) such that the cache
    1114             behavior will remain minimally correct even if the cache does not understand the
    1115             extension(s).</t>
     1069          <t>Unrecognized cache directives &MUST; be ignored; it is assumed that any cache
     1070            directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard
     1071            directives (or the response's default cacheability) such that the cache behavior will
     1072            remain minimally correct even if the cache does not understand the extension(s).</t>
    11161073        </section>
    11171074
    … …  
    11441101            <t>
    11451102              <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age
    1146               directive (see <xref target="header.cache-control" />), that directive overrides the
    1147               Expires field.</t>
     1103              directive (see <xref target="cache-response-directive" />), that directive overrides
     1104              the Expires field.</t>
    11481105          </list>
    11491106        </t>
    … …  
    11721129        <t>When the no-cache directive is present in a request message, an application &SHOULD;
    11731130          forward the request toward the origin server even if it has a cached copy of what is being
    1174           requested. This pragma directive has the same semantics as the no-cache cache-directive
    1175           (see <xref target="header.cache-control" />) and is defined here for backward
     1131          requested. This pragma directive has the same semantics as the no-cache response directive
     1132          (see <xref target="cache-response-directive" />) and is defined here for backward
    11761133          compatibility with HTTP/1.0. Clients &SHOULD; include both header fields when a
    11771134          no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches
    … …  
    12051162</artwork>
    12061163        </figure>
    1207         <t>The set of header fields named by the Vary field value is known as the "selecting" 
     1164        <t>The set of header fields named by the Vary field value is known as the "selecting"
    12081165          request-headers.</t>
    1209         <t>Servers &SHOULD; include a Vary header field with any cacheable response
    1210           that is subject to server-driven negotiation. Doing so allows a cache to properly
    1211           interpret future requests on that resource and informs the user agent about the presence
    1212           of negotiation on that resource. A server &MAY; include a Vary header field with a
    1213           non-cacheable response that is subject to server-driven negotiation, since this might
    1214           provide the user agent with useful information about the dimensions over which the
    1215           response varies at the time of the response.</t>
     1166        <t>Servers &SHOULD; include a Vary header field with any cacheable response that is
     1167          subject to server-driven negotiation. Doing so allows a cache to properly interpret future
     1168          requests on that resource and informs the user agent about the presence of negotiation on
     1169          that resource. A server &MAY; include a Vary header field with a non-cacheable
     1170          response that is subject to server-driven negotiation, since this might provide the user
     1171          agent with useful information about the dimensions over which the response varies at the
     1172          time of the response.</t>
    12161173        <t>A Vary field value of "*" signals that unspecified parameters not limited to the
    12171174          request-headers (e.g., the network address of the client), play a role in the selection of
    … …  
    12201177        <t>The field-names given are not limited to the set of standard request-header fields
    12211178          defined by this specification. Field names are case-insensitive.</t>
    1222         <t>
    1223           <cref>ISSUE: Does 'server' here imply that non-origin servers can generate vary? note use of 'proxy'</cref></t>
    12241179      </section>
    12251180
    … …  
    12371192          information is typically used to warn about possible incorrectness introduced by caching
    12381193          operations or transformations applied to the entity body of the message.</t>
    1239         <t>Warnings MAY be used for other purposes, both cache-related and otherwise. The use of a
     1194        <t>Warnings can be used for other purposes, both cache-related and otherwise. The use of a
    12401195          warning, rather than an error status code, distinguish these responses from true failures.</t>
    12411196
    … …  
    12621217          a cache), including multiple warnings with the same code number. For example, a server
    12631218          might provide the same warning with texts in both English and Basque.</t>
    1264         <t>When this occurs, the user agent ought to inform the user of as many of them as possible,
    1265           in the order that they appear in the response. If it is not possible to inform the user of
    1266           all of the warnings, the user agent SHOULD follow these heuristics: <list style="symbols">
     1219        <t>When this occurs, the user agent &SHOULD; inform the user of as many of them as
     1220          possible, in the order that they appear in the response. If it is not possible to inform
     1221          the user of all of the warnings, the user agent &SHOULD; follow these heuristics:
     1222            <list style="symbols">
    12671223            <t>Warnings that appear early in the response take priority over those appearing later
    12681224              in the response.</t>
    … …  
    12781234          Warning is required to be deleted from a stored response after validation: <list
    12791235            style="symbols">
    1280             <t>1xx Warnings that describe the freshness or validation status of the response, and
    1281               so MUST be deleted by caches after validation. They MUST NOT be generated by a cache except when
    1282               validating a cached entry, and MUST NOT be generated by clients.</t>
     1236            <t>1xx Warnings that describe the freshness or validation status of the response, and so
     1237              &MUST; be deleted by caches after validation. They &MUST-NOT; be generated by a cache
     1238              except when validating a cached entry, and &MUST-NOT; be generated by clients.</t>
    12831239            <t>2xx Warnings that describe some aspect of the entity body or entity headers that is
    1284               not rectified by a validation (for example, a lossy compression of the entity
    1285               bodies) and which MUST NOT be deleted by caches after validation, unless a full
    1286               response is returned, in which case they MUST be.</t>
     1240              not rectified by a validation (for example, a lossy compression of the entity bodies)
     1241              and which &MUST-NOT; be deleted by caches after validation, unless a full response is
     1242              returned, in which case they &MUST; be.</t>
    12871243          </list>
    12881244        </t>
    12891245        <t>The warn-text &SHOULD; be in a natural language and character set that is most likely
    1290           to be intelligible to the human user receiving the response. This decision &MAY; be
    1291           based on any available knowledge, such as the location of the cache or user, the
    1292           Accept-Language field in a request, the Content-Language field in a response, etc. The
    1293           default language is English and the default character set is ISO-8859-1 (<xref
    1294             target="ISO-8859-1" />).</t>
     1246          to be intelligible to the human user receiving the response. This decision can be based on
     1247          any available knowledge, such as the location of the cache or user, the Accept-Language
     1248          field in a request, the Content-Language field in a response, etc. The default language is
     1249          English and the default character set is ISO-8859-1 (<xref target="ISO-8859-1" />).</t>
    12951250        <t>If a character set other than ISO-8859-1 is used, it &MUST; be encoded in the
    12961251          warn-text using the method described in <xref target="RFC2047" />.</t>
    … …  
    13011256          and that warn-date is different from the Date value in the response, then that
    13021257          warning-value &MUST; be deleted from the message before storing, forwarding, or using
    1303           it. (This prevents bad consequences of naive caching of Warning header fields.) If all of
    1304           the warning-values are deleted for this reason, the Warning header &MUST; be deleted
    1305           as well.</t>
     1258          it. (preventing the consequences of naive caching of Warning header fields.) If all of the
     1259          warning-values are deleted for this reason, the Warning header &MUST; be deleted as
     1260          well.</t>
    13061261        <t>The following warn-codes are defined by this specification, each with a recommended
    13071262          warn-text in English, and a description of its meaning.</t>
    13081263        <t>110 Response is stale <list>
    1309             <t>&MUST; be included whenever the returned response is stale.</t>
     1264            <t>&SHOULD; be included whenever the returned response is stale.</t>
    13101265          </list>
    13111266        </t>
    13121267        <t>111 Revalidation failed <list>
    1313             <t>&MUST; be included if a cache returns a stale response because an attempt to
     1268            <t>&SHOULD; be included if a cache returns a stale response because an attempt to
    13141269              validate the response failed, due to an inability to reach the server.</t>
    13151270          </list>
    … …  
    13211276        </t>
    13221277        <t>113 Heuristic expiration <list>
    1323             <t>&MUST; be included if the cache heuristically chose a freshness lifetime greater
    1324               than 24 hours and the response's age is greater than 24 hours.</t>
     1278            <t>&SHOULD; be included if the cache heuristically chose a freshness lifetime
     1279              greater than 24 hours and the response's age is greater than 24 hours.</t>
    13251280          </list>
    13261281        </t>
    … …  
    14321387
    14331388    <section anchor="security.considerations" title="Security Considerations">
    1434       <t>Caches expose additional potential vulnerabilities, since the contents of the
    1435         cache represent an attractive target for malicious exploitation. Because cache contents
    1436         persist after an HTTP request is complete, an attack on the cache can reveal information
    1437         long after a user believes that the information has been removed from the network.
    1438         Therefore, cache contents should be protected as sensitive information.</t>
     1389      <t>Caches expose additional potential vulnerabilities, since the contents of the cache
     1390        represent an attractive target for malicious exploitation. Because cache contents persist
     1391        after an HTTP request is complete, an attack on the cache can reveal information long after
     1392        a user believes that the information has been removed from the network. Therefore, cache
     1393        contents should be protected as sensitive information.</t>
    14391394    </section>
    14401395
Note: See TracChangeset for help on using the changeset viewer.