Changeset 1380


Ignore:
Timestamp:
Aug 5, 2011, 6:32:08 PM (8 years ago)
Author:
fielding@…
Message:

Editorial. Rewrite the requirements on weak and strong validators
so that they are all in one section.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1379 r1380  
    223223<t>
    224224   This document defines the HTTP/1.1 conditional request mechanisms,
    225    including both response metadata that can be used to indicate or
    226    observe changes to resource state and request header fields that
    227    specify preconditions to be checked before performing the action
    228    given by the request method.  Conditional GET requests are the most
    229    efficient mechanism for HTTP cache updates &caching;.  Conditionals
    230    can also be
     225   including both metadata for indicating/observing changes in resource
     226   representations and request header fields that specify preconditions
     227   on that metadata be checked before performing the request method.
     228   Conditional GET requests are the most efficient mechanism for HTTP
     229   cache updates &caching;.  Conditionals can also be
    231230   applied to state-changing methods, such as PUT and DELETE, to prevent
    232231   the "lost update" problem: one client accidentally overwriting
     
    311310</section>
    312311
    313 <section title="Resource State Metadata (Validators)" anchor="resource.metadata">
     312<section title="Validators" anchor="validators">
    314313   <iref primary="true" item="metadata"/>
    315314   <iref primary="true" item="validator"/>
     
    325324
    326325<section title="Weak versus Strong" anchor="weak.and.strong.validators">
    327 <t>
    328    Since both origin servers and caches will compare two validators to
    329    decide if they indicate the same or different representations, one
    330    normally would expect that if the representation (including both
    331    representation header fields and representation body) changes in any
    332    way, then the associated validator would change as well. If this is
    333    true, then we call that validator a "strong validator".  One example
    334    of a strong validator is an integer that is incremented in stable
    335    storage every time a representation is changed.
    336 </t>
    337 <t>
    338    However, there might be cases when a server prefers to change the
    339    validator only when it desires cached representations to be invalidated.
     326   <iref primary="true" item="validator" subitem="weak"/>
     327   <iref primary="true" item="validator" subitem="strong"/>
     328<t>
     329   Validators come in two flavors: strong or weak.  Weak validators are easy
     330   to generate but are far less useful for comparisons.  Strong validators
     331   are ideal for comparisons but can be very difficult (and occasionally
     332   impossible) to generate efficiently.  Rather than impose that all forms
     333   of resource adhere to the same strength of validator, HTTP exposes the
     334   type of validator in use and imposes restrictions on when weak validators
     335   can be used as preconditions.
     336</t>
     337<t>
     338   A "strong validator" is a representation metadata value that &MUST; be
     339   changed to a new, previously unused or guaranteed unique, value whenever
     340   a change occurs to the representation data such that a change would be
     341   observable in the payload body of a 200 response to GET.  A strong
     342   validator &MAY; be changed for other reasons, such as when a semantically
     343   significant part of the representation metadata is changed (e.g.,
     344   Content-Type), but it is in the best interests of the origin server to only
     345   change the value when it is necessary to invalidate the stored responses
     346   held by remote caches and authoring tools.  A strong validator &MUST; be
     347   unique across all representations of a given resource, such that no two
     348   representations of that resource share the same validator unless
     349   their payload body would be identical.
     350</t>
     351<t>
     352   Cache entries might persist for arbitrarily long periods, regardless
     353   of expiration times.  Thus, a cache might attempt to validate an
     354   entry using a validator that it obtained in the distant past.
     355   A strong validator &MUST; be unique across all versions of all
     356   representations associated with a particular resource over time.
     357   However, there is no implication of uniqueness across representations
     358   of different resources (i.e., the same strong validator might be
     359   in use for representations of multiple resources at the same time
     360   and does not imply that those representations are equivalent).
     361</t>
     362<t>
     363   There are a variety of strong validators used in practice.  The best are
     364   based on strict revision control, wherein each change to a representation
     365   always results in a unique node name and revision identifier being assigned
     366   before the representation is made accessible to GET.  A cryptographic hash
     367   function applied to the representation data is also sufficient if the data
     368   is available prior to the response header fields being sent and the digest
     369   does not need to be recalculated every time a validation request is
     370   received.  However, if a resource has distinct representations that differ
     371   only in their metadata, such as might occur with content negotiation over
     372   media types that happen to share the same data format, then a server
     373   &SHOULD; incorporate additional information in the validator to
     374   distinguish those representations and avoid confusing cache behavior.
     375</t>
     376<t>
     377   In contrast, a "weak validator" is a representation metadata value that
     378   might not be changed for every change to the representation data.  This
     379   weakness might be due to limitations in how the value is calculated, such
     380   as clock resolution or an inability to ensure uniqueness for all possible
     381   representations of the resource, or due to a desire by the resource owner
     382   to group representations by some self-determined set of equivalency
     383   rather than unique sequences of data.  A weak entity-tag &SHOULD; change
     384   whenever the origin server considers prior representations to be
     385   unacceptable as a substitute for the current representation. In other
     386   words, a weak entity-tag &SHOULD; change whenever the origin server wants
     387   caches to invalidate old responses.
     388</t>
     389<t>
    340390   For example, the representation of a weather report that changes in
    341391   content every second, based on dynamic measurements, might be grouped
    342392   into sets of equivalent representations (from the origin server's
    343    perspective) in order to allow cached representations to be valid
    344    for a reasonable period of time (perhaps adjusted dynamically based
    345    on server load or weather quality).
    346    A validator that does not always change when the representation
    347    changes is a "weak validator".
    348 </t>
    349 <t>
    350    One can think of a strong validator as part of an identifier for a
    351    specific representation, whereas a weak validator is part of an
    352    identifier for a set of equivalent representations (where this notion
    353    of equivalence is entirely governed by the origin server and beyond
    354    the scope of this specification).
    355 </t>
    356 <t>
    357       A representation's modification time, if defined with only one-second
    358       resolution, could be a weak validator, since it is possible that
    359       the representation might be modified twice during a single second.
    360 </t><t>
    361       Support for weak validators is optional. However, weak validators
    362       allow for more efficient caching of equivalent objects; for
    363       example, a hit counter on a site is probably good enough if it is
    364       updated every few days or weeks, and any value during that period
    365       is likely "good enough" to be equivalent.
    366 </t>
    367 <t>
    368    A strong entity-tag &MUST; change whenever the associated representation
    369    changes in any way. A weak entity-tag &SHOULD; change whenever the origin
    370    server considers prior representations to be unacceptable as a substitute
    371    for the current representation. In other words, a weak entity tag &SHOULD;
    372    change whenever the origin server wants caches to invalidate old responses.
    373 </t>
    374 <t>
    375    A "strong entity-tag" &MAY; be shared by two representations of a resource
    376    only if they are equivalent by octet equality.
    377 </t>
    378 <t>
    379    A "weak entity-tag", indicated by the "W/" prefix, &MAY; be shared by
    380    two representations of a resource. A weak entity-tag can only be used
    381    for weak comparison.
    382 </t>
    383 <t>
    384    Cache entries might persist for arbitrarily long periods, regardless
    385    of expiration times.  Thus, a cache might attempt to validate an
    386    entry using a validator that it obtained in the distant past.
    387    A strong entity-tag &MUST; be unique across all versions of all
    388    representations associated with a particular resource over time.
    389    However, there is no implication of uniqueness across entity-tags
    390    of different resources (i.e., the same entity-tag value might be
    391    in use for representations of multiple resources at the same time
    392    and does not imply that those representations are equivalent).
    393 </t>
    394 <t>
    395    A "use" of a validator is either when a client generates a request
    396    and includes the validator in a precondition, or when a server
     393   perspective) with the same weak validator in order to allow cached
     394   representations to be valid for a reasonable period of time (perhaps
     395   adjusted dynamically based on server load or weather quality).
     396   Likewise, a representation's modification time, if defined with only
     397   one-second resolution, might be a weak validator if it is possible
     398   for the representation to be modified twice during a single second and
     399   retrieved between those modifications.
     400</t>
     401<t>
     402   A "use" of a validator occurs when either a client generates a request
     403   and includes the validator in a precondition or when a server
    397404   compares two validators.
    398 </t>
    399 <t>
    400    Strong validators are usable in any context. Weak validators are only
    401    usable in contexts that do not depend on exact equality of a representation.
    402    For example, either kind is usable for a normal conditional GET.
     405   Weak validators are only usable in contexts that do not depend on exact
     406   equality of a representation's payload body.
     407   Strong validators are usable and preferred for all conditional requests,
     408   including cache validation, partial content ranges, and "lost update"
     409   avoidance.
    403410</t>
    404411</section>
     
    768775</t>
    769776</section>
    770 
    771777</section>
    772778
Note: See TracChangeset for help on using the changeset viewer.