Changeset 1374


Ignore:
Timestamp:
Aug 3, 2011, 10:41:28 PM (8 years ago)
Author:
fielding@…
Message:

Clarify what should happen when a response is incomplete.
Disentangle the requirements surrounding conditional range
requests, strong validators, and recombining partial content
to remove redundant redundancy. Separate handling of 304
responses into a separate section on cache freshening.

Add definitions for "cache entry" and "cache key".
Improve introductions for caching and cache operation.

These changes should all be editorial, hopefully.
Tangentially related to #101 and #304.

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1373 r1374  
    1717  <!ENTITY mdash "&#8212;">
    1818  <!ENTITY caching-overview       "<xref target='Part6' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    19   <!ENTITY cache-incomplete       "<xref target='Part6' x:rel='#errors.or.incomplete.response.cache.behavior' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     19  <!ENTITY cache-incomplete       "<xref target='Part6' x:rel='#response.cacheability' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2020  <!ENTITY payload                "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2121  <!ENTITY media-types            "<xref target='Part3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    15611561   received response.
    15621562</t>
     1563</section>
     1564
     1565<section anchor="incomplete.messages" title="Incomplete Messages">
    15631566<t>
    15641567   Request messages that are prematurely terminated, possibly due to a
    … …  
    15661569   result in closure of the connection; sending an HTTP/1.1 error response
    15671570   prior to closing the connection is &OPTIONAL;.
     1571</t>
     1572<t>
    15681573   Response messages that are prematurely terminated, usually by closure
    15691574   of the connection prior to receiving the expected number of octets or by
    15701575   failure to decode a transfer-encoded message-body, &MUST; be recorded
    1571    as incomplete.  A user agent &MUST-NOT; render an incomplete response
    1572    message-body as if it were complete (i.e., some indication must be given
    1573    to the user that an error occurred).  Cache requirements for incomplete
    1574    responses are defined in &cache-incomplete;.
     1576   as incomplete.  A response that terminates in the middle of the header
     1577   block (before the empty line is received) cannot be assumed to convey the
     1578   full semantics of the response and &MUST-NOT; be stored by a cache.
     1579</t>
     1580<t>
     1581   A message-body that uses the chunked transfer encoding is
     1582   incomplete if the zero-sized chunk that terminates the encoding has not
     1583   been received.  A message that uses a valid Content-Length is incomplete
     1584   if the size of the message-body received (in octets) is less than the
     1585   value given by Content-Length.  A response that has neither chunked
     1586   transfer encoding nor Content-Length is terminated by closure of the
     1587   connection, and thus is considered complete regardless of the number of
     1588   message-body octets received, provided that the header block was received
     1589   intact.
     1590</t>
     1591<t>
     1592   A user agent &MUST-NOT; render an incomplete response message-body as if
     1593   it were complete (i.e., some indication must be given to the user that an
     1594   error occurred).  Cache requirements for incomplete responses are defined
     1595   in &cache-incomplete;.
    15751596</t>
    15761597<t>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1373 r1374  
    2424  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2525  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    26   <!ENTITY combining-responses        "<xref target='Part6' x:rel='#combining.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2726  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2827  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    725724   <t>If the response status code is 204, 206, or 304 and the request method was GET
    726725   or HEAD, the response payload is a partial representation of the target
    727    resource (see &combining-responses;).</t>
     726   resource.</t>
    728727   <t>If the response has a Content-Location header field, and that URI is the same
    729728   as the effective request URI, the response payload is a representation of the

  • draft-ietf-httpbis/latest/p5-range.xml

    r1373 r1374  
    216216<t>
    217217   HTTP clients often encounter interrupted data transfers as a result
    218    of cancelled requests or dropped connections.  When a cache has stored
     218   of cancelled requests or dropped connections.  When a client has stored
    219219   a partial representation, it is desirable to request the remainder
    220220   of that representation in a subsequent request rather than transfer
    … …  
    407407   with a 200 (OK) response to the same request.
    408408</t>
    409 <t>
    410    A cache &MUST-NOT; combine a 206 response with other previously cached
    411    content if the ETag or Last-Modified header fields do not match exactly,
    412    see <xref target="combining.byte.ranges"/>.
    413 </t>
    414 <t>
    415    A cache that does not support the Range and Content-Range header fields
    416    &MUST-NOT; cache 206 (Partial Content) responses. Furthermore,
    417    if a response uses a range unit that is not understood by the cache,
    418    then it &MUST-NOT; be cached either.
    419 </t>
    420409</section>
    421410
    … …  
    443432<section title="Combining Ranges" anchor="combining.byte.ranges">
    444433<t>
    445    A response might transfer only a subrange of a representation, either because
    446    the request included one or more Range specifications, or because
    447    a connection closed prematurely.
    448    After several such transfers, a cache might have received several
    449    ranges of the same representation.
    450 </t>
    451 <t>
    452    If a cache has a stored non-empty set of subranges for a representation, and
    453    an incoming response transfers another subrange, the cache &MAY;
    454    combine the new subrange with the existing set if both the following
    455    conditions are met:
    456   <list style="symbols">
    457     <t>Both the incoming response and the cache entry have a cache
    458         validator.</t>
    459     <t>The two cache validators match using the strong comparison
    460         function (see &weak-and-strong-validators;).</t>
    461   </list>
    462 </t>
    463 <t>
    464    If either requirement is not met, the cache &MUST; use only the most
    465    recent partial response (based on the Date values transmitted with
    466    every response, and using the incoming response if these values are
    467    equal or missing), and &MUST; discard the other partial information.
     434   A response might transfer only a subrange of a representation if the
     435   connection closed prematurely or if the request used one or more Range
     436   specifications.  After several such transfers, a client might have
     437   received several ranges of the same representation.  These ranges can only
     438   be safely combined if they all have in common the same strong validator,
     439   where "strong validator" is defined to be either an entity-tag that is
     440   not marked as weak (&entity-tags;) or, if no entity-tag is provided, a
     441   Last-Modified value that is strong in the sense defined by
     442   &lastmod-comparison;.
     443</t>
     444<t>
     445   When a client receives an incomplete 200 (OK) or 206 (Partial Content)
     446   response and already has one or more stored responses for the same method
     447   and effective request URI, all of the stored responses with the same
     448   strong validator &MAY; be combined with the partial content in this new
     449   response.  If none of the stored responses contain the same strong
     450   validator, then this new response corresponds to a new representation
     451   and &MUST-NOT; be combined with the existing stored responses.
     452</t>
     453<t>
     454   If the new response is an incomplete 200 (OK) response, then the header
     455   fields of that new response are used for any combined response and replace
     456   those of the matching stored responses.
     457</t>
     458<t>
     459   If the new response is a 206 (Partial Content) response and at least one
     460   of the matching stored responses is a 200 (OK), then the combined response
     461   header fields consist of the most recent 200 response's header fields.
     462   If all of the matching stored responses are 206 responses, then the
     463   stored response with the most header fields is used as the source of
     464   header fields for the combined response, except that the client &MUST;
     465   use other header fields provided in the new response, aside from
     466   Content-Range, to replace all instances of the corresponding header
     467   fields in the stored response.
     468</t>
     469<t>
     470   The combined response message-body consists of the union of partial
     471   content ranges in the new response and each of the selected responses.
     472   If the union consists of the entire range of the representation, then the
     473   combined response &MUST; be recorded as a complete 200 (OK) response
     474   with a Content-Length header field that reflects the complete length.
     475   Otherwise, the combined response(s) &MUST; include a Content-Range
     476   header field describing the included range(s) and be recorded as
     477   incomplete.  If the union consists of a discontinuous range of the
     478   representation, then the client &MAY; store it as either a multipart range
     479   response or as multiple 206 responses with one continuous range each.
    468480</t>
    469481</section>
    … …  
    668680  <x:anchor-alias value="If-Range"/>
    669681<t>
    670    If a client has a partial copy of a representation in its cache, and wishes
    671    to have an up-to-date copy of the entire representation in its cache, it
     682   If a client has a partial copy of a representation and wishes
     683   to have an up-to-date copy of the entire representation, it
    672684   could use the Range header field with a conditional GET (using
    673685   either or both of If-Unmodified-Since and If-Match.) However, if the
    … …  
    686698</artwork></figure>
    687699<t>
    688    Only a strong validator (&weak-and-strong-validators;) is usable for
    689    range retrieval, since otherwise the client might end up with an
    690    internally inconsistent representation.
    691    Clients &MUST-NOT; use weak validators in range requests.
    692    A cache or origin server receiving a conditional range request
    693    &MUST; use the strong comparison function to evaluate the condition.
    694 </t>
    695 <t>
    696    If the client has no entity-tag for a representation, but does have a Last-Modified
    697    date, it &MAY; use that date in an If-Range header field. (The
    698    server can distinguish between a valid HTTP-date and any form of
    699    entity-tag by examining no more than two characters.) The If-Range
    700    header field &SHOULD; only be used together with a Range header field, and &MUST; be
    701    ignored if the request does not include a Range header field, or if the
    702    server does not support the sub-range operation.
    703 </t>
    704 <t>
    705    If a client wishes to perform a sub-range retrieval on a value for
    706    which it has only a Last-Modified time and no opaque validator, it
    707    &MAY; do this only if the Last-Modified time is strong in the sense
    708    described in &lastmod-comparison;.
    709 </t>
    710 <t>
    711    If the entity-tag given in the If-Range header field matches the current
    712    cache validator for the representation, then the server &SHOULD; provide the
    713    specified sub-range of the representation using a 206 (Partial Content)
    714    response. If the cache validator does not match, then the server &SHOULD;
    715    return the entire representation using a 200 (OK) response.
     700   Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range
     701   field value and &MUST-NOT; use a Last-Modified date in an If-Range
     702   field value unless it has no entity-tag for the representation and
     703   the Last-Modified date it does have for the representation is strong
     704   in the sense defined by &lastmod-comparison;.
     705</t>
     706<t>
     707   A server that evaluates a conditional range request that is applicable
     708   to one of its representations &MUST; evaluate the condition as false if
     709   the entity-tag used as a validator is marked as weak or, when an HTTP-date
     710   is used as the validator, if the date value is not strong in the sense
     711   defined by &lastmod-comparison;. (A server can distinguish between a
     712   valid HTTP-date and any form of entity-tag by examining the first
     713   two characters.)
     714</t>
     715<t>
     716   The If-Range header field &SHOULD; only be sent by clients together with
     717   a Range header field.  The If-Range header field &MUST; be ignored if it
     718   is received in a request that does not include a Range header field.
     719   The If-Range header field &MUST; be ignored by a server that does not
     720   support the sub-range operation.
     721</t>
     722<t>
     723   If the validator given in the If-Range header field matches the current
     724   validator for the selected representation of the target resource, then
     725   the server &SHOULD; send the specified sub-range of the representation
     726   using a 206 (Partial Content) response. If the validator does not match,
     727   then the server &SHOULD; send the entire representation using a 200 (OK)
     728   response.
    716729</t>
    717730</section>
    … …  
    851864</artwork></figure>
    852865<t>
    853    A server &MAY; ignore the Range header field. However, HTTP/1.1 origin
     866   A server &MAY; ignore the Range header field. However, origin
    854867   servers and intermediate caches ought to support byte ranges when
    855868   possible, since Range supports efficient recovery from partially
    … …  
    13841397<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    13851398<t>
    1386   Clarify that it is not ok to use a weak cache validator in a 206 response.
     1399  Clarify that it is not ok to use a weak validator in a 206 response.
    13871400  (<xref target="status.206"/>)
    13881401</t>

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

    r1373 r1374  
    2121  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2222  <!ENTITY messaging                   "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     23  <!ENTITY semantics                   "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2324  <!ENTITY conditional                 "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2425  <!ENTITY partial                     "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    3233  <!ENTITY header-fields               "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3334  <!ENTITY safe-methods                "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     35  <!ENTITY entity-tags                 "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3436  <!ENTITY weak-and-strong             "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     37  <!ENTITY lastmod-comparison          "<xref target='Part4' x:rel='#lastmod.comparison' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3538  <!ENTITY status-codes                "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3639  <!ENTITY status.2xx                  "<xref target='Part2' x:rel='#status.2xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    252255</t>
    253256<t>
    254    Caching would be useless if it did not significantly improve performance.
    255    The goal of caching in HTTP/1.1 is to reuse a prior response message to
    256    satisfy a current request. In some cases, a stored response can be reused
    257    without the need for a network request, reducing latency and network
    258    round-trips; a "freshness" mechanism is used for this purpose (see <xref
    259    target="expiration.model" />). Even when a new request is required, it is
    260    often possible to reuse all or parts of the payload of a prior response to
    261    satisfy the request, thereby reducing network bandwidth usage; a
    262    "validation" mechanism is used for this purpose (see <xref
    263    target="validation.model" />).
     257   The goal of caching in HTTP/1.1 is to significantly improve performance
     258   by reusing a prior response message to satisfy a current request.
     259   A stored response is considered "fresh", as defined in
     260   <xref target="expiration.model" />, if the response can be reused without
     261   "validation" (checking with the origin server to see if the cached response
     262   remains valid for this request).  A fresh cache response can therefore
     263   reduce both latency and network transfers each time it is reused.
     264   When a cached response is not fresh, it might still be reusable if it can
     265   be freshened by validation (<xref target="validation.model" />) or if the
     266   origin is unavailable.
    264267</t>
    265268</section>
    … …  
    283286   <x:dfn>shared cache</x:dfn>
    284287   <list>
    285       <t>A cache that is accessible to more than one user; usually (but
    286         not always) deployed as part of an intermediary.</t>
     288      <t>A cache that stores responses to be reused by more than one user;
     289         usually (but not always) deployed as part of an intermediary.</t>
    287290   </list>
    288291</t>
    … …  
    366369      <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that
    367370      is used to find out whether a stored response is an equivalent copy of
    368       a representation.</t>
     371      a representation. See &weak-and-strong;.</t>
     372   </list>
     373</t>
     374<t>
     375   <iref item="strong validator" />
     376   <iref item="validator, strong" />
     377   <x:dfn>strong validator</x:dfn>
     378   <list>
     379      <t>A validator that is defined by the origin server such that its
     380         current value will change if the representation body changes; i.e.,
     381         an entity-tag that is not marked as weak (&entity-tags;) or,
     382         if no entity-tag is provided, a Last-Modified value that is strong
     383         in the sense defined by &lastmod-comparison;.</t>
    369384   </list>
    370385</t>
    … …  
    468483
    469484<section anchor="caching.overview" title="Cache Operation">
     485<iref item="cache entry" />
     486<iref item="cache key" />
     487<t>
     488   Proper cache operation preserves the semantics of HTTP transfers
     489   (&semantics;) while eliminating the transfer of information already held
     490   in the cache.  Although caching is an entirely &OPTIONAL; feature of HTTP,
     491   we assume that reusing the cached response is desirable and that such
     492   reuse is the default behavior when no requirement or locally-desired
     493   configuration prevents it.  Therefore, HTTP cache requirements are focused
     494   on preventing a cache from either storing a non-reusable response or
     495   reusing a stored response inappropriately.
     496</t>
     497<t>
     498   Each <x:dfn>cache entry</x:dfn> consists of a cache key and one or more
     499   HTTP responses corresponding to prior requests that used the same key.
     500   The most common form of cache entry is a successful result of a retrieval
     501   request: i.e., a 200 (OK) response containing a representation of the
     502   resource identified by the request target.  However, it is also possible
     503   to cache negative results (e.g., 404 not found), incomplete results
     504   (e.g., 206 partial content), and responses to safe methods other than
     505   GET if the method's definition allows such caching and defines something
     506   suitable for use as a cache key.
     507</t>
     508<t>
     509   The default <x:dfn>cache key</x:dfn> consists of the request method and
     510   target URI.  However, since HTTP caches in common use today are typically
     511   limited to caching responses to GET, most implementations simply decline
     512   other methods and use only the URI as the key.
     513</t>
     514<t>
     515   If a request target is subject to content negotiation, its cache entry
     516   might consist of multiple stored responses, each differentiated by a
     517   secondary key for the values of the original request's selecting header
     518   fields (<xref target="caching.negotiated.responses"/>).
     519</t>
    470520
    471521<section anchor="response.cacheability" title="Response Cacheability">
    … …  
    509559<t>
    510560   In this context, a cache has "understood" a request method or a response
    511    status code if it recognises it and implements any cache-specific
    512    behavior. In particular, 206 Partial Content responses cannot be cached by
    513    an implementation that does not handle partial content (see <xref
    514    target="errors.or.incomplete.response.cache.behavior" />).
    515 </t>
    516 <t>
    517    Note that in normal operation, most caches will not store a response that
     561   status code if it recognizes it and implements any cache-specific
     562   behavior.
     563</t>
     564<t>
     565   Note that, in normal operation, most caches will not store a response that
    518566   has neither a cache validator nor an explicit expiration time, as such
    519567   responses are not usually useful to store. However, caches are not
    520568   prohibited from storing such responses.
    521569</t>
    522 
    523 <section anchor="errors.or.incomplete.response.cache.behavior"
    524    title="Storing Partial and Incomplete Responses">
    525 <t>
    526    A cache that receives an incomplete response (for example, with fewer bytes
    527    of data than specified in a Content-Length header field) can store the response,
    528    but &MUST; treat it as a partial response &partial;. Partial responses can
    529    be combined as described in &combining-byte-ranges;; the result might be a
    530    full response or might still be partial. A cache &MUST-NOT; return a
    531    partial response to a client without explicitly marking it as such using
    532    the 206 (Partial Content) status code.
    533 </t>
    534 <t>
    535    A cache that does not support the Range and Content-Range header fields
    536    &MUST-NOT; store incomplete or partial responses.
    537 </t>
    538 </section>
    539 
     570<t>
     571   A response message is considered complete when all of the octets
     572   indicated by the message framing (&messaging;) are received
     573   prior to the connection being closed.
     574   If the request is GET, the response status is 200 (OK), and the entire
     575   response header block has been received, a cache &MAY; store an incomplete
     576   response message-body if the cache entry is recorded as incomplete.
     577   Likewise, a 206 (Partial Content) response &MAY; be stored as if it were
     578   an incomplete 200 (OK) cache entry.  However, a cache &MUST-NOT; store
     579   incomplete or partial content responses if it does not support the Range
     580   and Content-Range header fields or if it does not understand the
     581   range units used in those fields.
     582</t>
     583<t>
     584   A cache &MAY; complete a stored incomplete response by making a subsequent
     585   range request (&partial;) and combining the successful response with the
     586   stored entry, as defined in <xref target="combining.responses"/>.
     587   A cache &MUST-NOT; use an incomplete response to answer requests
     588   unless the response has been made complete or the request is partial and
     589   specifies a range that is wholly within the incomplete response.
     590   A cache &MUST-NOT; send a partial response to a client without explicitly
     591   marking it as such using the 206 (Partial Content) status code.
     592</t>
    540593</section>
    541594
    … …  
    881934<t>
    882935   A 304 (Not Modified) response status code indicates that the stored
    883    response can be updated and reused; see <xref target="combining.responses"/>.
     936   response can be updated and reused; see <xref target="freshening.responses"/>.
    884937</t>
    885938<t>
    … …  
    887940   stored responses nominated in the conditional request is suitable. Instead,
    888941   a cache &SHOULD; use the full response to satisfy the request and &MAY;
    889    replace the stored response.
     942   replace the stored response(s).
    890943</t>
    891944<t>
    … …  
    10161069</section>
    10171070
    1018 <section anchor="combining.responses" title="Combining Responses">
    1019 <t>
    1020    When a cache receives a 304 (Not Modified) response or a 206 (Partial
    1021    Content) response (in this section, the "new" response"), it needs to
    1022    create an updated response by combining the stored response with the new
    1023    one, so that the updated response can be used to satisfy the request, and
    1024    potentially update the cached response.
    1025 </t>
    1026 <t>
    1027    If the new response contains an ETag, it identifies the stored response to
    1028    use. <cref anchor="TODO-mention-CL">might need language about
    1029    Content-Location here</cref><cref
    1030    anchor="TODO-select-for-combine">Shouldn't this be the selected
    1031    response?</cref>
    1032 </t>
    1033 <t>
    1034    When the new response's status code is 206 (partial content), a cache
    1035    &MUST-NOT; combine it with the old response if either response does not
    1036    have a validator, and &MUST-NOT; combine it with the old response when
    1037    those validators do not match with the strong comparison function
    1038    (see &weak-and-strong;).
    1039 </t>
    1040 <t>
    1041    The stored response header fields are used as those of the updated response,
    1042    except that
     1071<section anchor="combining.responses" title="Combining Partial Content">
     1072<t>
     1073   A response might transfer only a partial representation if the
     1074   connection closed prematurely or if the request used one or more Range
     1075   specifiers (&partial;).  After several such transfers, a cache might have
     1076   received several ranges of the same representation.  A cache &MAY; combine
     1077   these ranges into a single stored response, and reuse that response to
     1078   satisfy later requests, if they all share the same strong validator and
     1079   the cache complies with the client requirements in &combining-byte-ranges;.
     1080</t>
     1081<t>
     1082   When combining the new response with one or more stored responses, a
     1083   cache &MUST;:
    10431084   <list style="symbols">
    1044       <t>a cache &MUST; delete any stored Warning header fields with warn-code 1xx (see <xref
    1045       target="header.warning" />).</t>
    1046       <t>a cache &MUST; retain any stored Warning header fields with warn-code 2xx.</t>
    1047       <t>a cache &MUST; use other header fields provided in the new response to replace all
    1048       instances of the corresponding header fields from the stored response.</t>
    1049    </list>
    1050 </t>
    1051 <t>
    1052    A cache &MUST; use the updated response header fields to replace those of the stored
    1053    response (unless the stored response is removed). In
    1054    the case of a 206 response, a cache &MAY; store the combined representation.
     1085      <t>delete any Warning header fields in the stored response with
     1086         warn-code 1xx (see <xref target="header.warning" />);</t>
     1087      <t>retain any Warning header fields in the stored response with
     1088         warn-code 2xx; and,</t>
     1089      <t>use other header fields provided in the new response, aside
     1090         from Content-Range, to replace all instances of the corresponding
     1091         header fields in the stored response.</t>
     1092   </list>
     1093</t>
     1094</section>
     1095
     1096<section anchor="freshening.responses" title="Freshening Responses">
     1097<t>
     1098   When a cache receives a 304 (Not Modified) response and already has one
     1099   or more stored 200 (OK) responses for the same cache key, the cache needs
     1100   to identify which of the stored responses are updated by this new response
     1101   and then update the stored response(s) with the new information provided in
     1102   the 304 response.
     1103   <list style="symbols">
     1104    <t>
     1105     If the new response contains a strong validator, then that strong
     1106     validator identifies the selected representation.  All of the stored
     1107     responses with the same strong validator are selected.
     1108     If none of the stored responses contain the same strong validator, then
     1109     this new response corresponds to a new selected representation and
     1110     &MUST-NOT; update the existing stored responses.
     1111    </t>
     1112    <t>
     1113     If the new response contains a weak validator and that validator
     1114     corresponds to one of the cache's stored responses, then the most
     1115     recent of those matching stored responses is selected.
     1116    </t>
     1117    <t>
     1118     If the new response does not include any form of validator, there is
     1119     only one stored response, and that stored response also lacks a
     1120     validator, then that stored response is selected.
     1121    </t>
     1122   </list>
     1123</t>
     1124<t>
     1125   If a stored response is selected for update, the cache &MUST;:
     1126   <list style="symbols">
     1127      <t>delete any Warning header fields in the stored response with
     1128         warn-code 1xx (see <xref target="header.warning" />);</t>
     1129      <t>retain any Warning header fields in the stored response with
     1130         warn-code 2xx; and,</t>
     1131      <t>use other header fields provided in the 304 response to replace
     1132         all instances of the corresponding header fields in the stored
     1133         response.</t>
     1134   </list>
    10551135</t>
    10561136</section>
Note: See TracChangeset for help on using the changeset viewer.