Ignore:
Timestamp:
04/08/11 05:41:28 (12 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.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • 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>
Note: See TracChangeset for help on using the changeset viewer.