Ignore:
Timestamp:
Jul 22, 2010, 2:06:27 AM (9 years ago)
Author:
fielding@…
Message:

Addresses #109: Clarify entity / representation / variant terminology

Replaced entity with representation.

File:
1 edited

Legend:

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

    r863 r866  
    456456<t>
    457457   Since both origin servers and caches will compare two validators to
    458    decide if they represent the same or different entities, one normally
    459    would expect that if the entity (the entity-body or any entity-headers)
    460    changes in any way, then the associated validator would
    461    change as well. If this is true, then we call this validator a
    462    "strong validator."
     458   decide if they represent the same or different representations, one normally
     459   would expect that if the representation (including both representation
     460   header fields and representation body) changes in any way, then the
     461   associated validator would change as well. If this is true, then we
     462   call this validator a "strong validator."
    463463</t>
    464464<t>
    465465   However, there might be cases when a server prefers to change the
    466466   validator only on semantically significant changes, and not when
    467    insignificant aspects of the entity change. A validator that does not
    468    always change when the resource changes is a "weak validator."
     467   insignificant aspects of the representation change. A validator that does not
     468   always change when the representation changes is a "weak validator."
    469469</t>
    470470<t>
    471471   Entity tags are normally "strong validators," but the protocol
    472472   provides a mechanism to tag an entity tag as "weak." One can think of
    473    a strong validator as one that changes whenever the bits of an entity
    474    changes, while a weak value changes whenever the meaning of an entity
    475    changes. Alternatively, one can think of a strong validator as part
    476    of an identifier for a specific entity, while a weak validator is
    477    part of an identifier for a set of semantically equivalent entities.
     473   a strong validator as one that changes whenever the sequence of bits
     474   in a representation changes, while a weak value changes whenever the
     475   meaning of a representation changes. Alternatively, one can think of
     476   a strong validator as part of an identifier for a specific representation,
     477   whereas a weak validator is part of an identifier for a set of semantically
     478   equivalent representations.
    478479  <list><t>
    479480      <x:h>Note:</x:h> One example of a strong validator is an integer that is
    480       incremented in stable storage every time an entity is changed.
     481      incremented in stable storage every time a representation is changed.
    481482    </t><t>
    482       An entity's modification time, if represented with one-second
     483      An entity's modification time, if defined with only one-second
    483484      resolution, could be a weak validator, since it is possible that
    484       the resource might be modified twice during a single second.
     485      the representation might be modified twice during a single second.
    485486    </t><t>
    486487      Support for weak validators is optional. However, weak validators
     
    498499<t>
    499500   Strong validators are usable in any context. Weak validators are only
    500    usable in contexts that do not depend on exact equality of an entity.
    501    For example, either kind is usable for a conditional GET of a full
    502    entity. However, only a strong validator is usable for a sub-range
     501   usable in contexts that do not depend on exact equality of a representation.
     502   For example, either kind is usable for a normal conditional GET.
     503   However, only a strong validator is usable for a sub-range
    503504   retrieval, since otherwise the client might end up with an internally
    504    inconsistent entity.
     505   inconsistent representation.
    505506</t>
    506507<t>
     
    562563  <list style="symbols">
    563564     <t>The validator is being compared by an origin server to the
    564         actual current validator for the entity and,</t>
    565      <t>That origin server reliably knows that the associated entity did
     565        actual current validator for the representation and,</t>
     566     <t>That origin server reliably knows that the associated representation did
    566567        not change twice during the second covered by the presented
    567568        validator.</t>
     
    573574     <t>The validator is about to be used by a client in an If-Modified-Since
    574575        or If-Unmodified-Since header, because the client
    575         has a cache entry for the associated entity, and</t>
     576        has a cache entry for the associated representation, and</t>
    576577     <t>That cache entry includes a Date value, which gives the time
    577578        when the origin server sent the original response, and</t>
     
    584585  <list style="symbols">
    585586     <t>The validator is being compared by an intermediate cache to the
    586         validator stored in its cache entry for the entity, and</t>
     587        validator stored in its cache entry for the representation, and</t>
    587588     <t>That cache entry includes a Date value, which gives the time
    588589        when the origin server sent the original response, and</t>
     
    726727<t>
    727728   For entity-header fields, both sender and recipient refer to either the
    728    client or the server, depending on who sends and who receives the entity.
     729   client or the server, depending on who sends and who receives the message.
    729730</t>
    730731
     
    796797</artwork></figure>
    797798<t>
    798    If any of the entity tags match the entity tag of the entity that
     799   If any of the entity tags match the entity tag of the representation that
    799800   would have been returned in the response to a similar GET request
    800801   (without the If-Match header) on that resource, or if "*" is given
     
    805806<t>
    806807   If none of the entity tags match, or if "*" is given and no current
    807    entity exists, the server &MUST-NOT; perform the requested method, and
     808   representation exists, the server &MUST-NOT; perform the requested method, and
    808809   &MUST; return a 412 (Precondition Failed) response. This behavior is
    809810   most useful when the client wants to prevent an updating method, such
     
    825826   A request intended to update a resource (e.g., a PUT) &MAY; include an
    826827   If-Match header field to signal that the request method &MUST-NOT; be
    827    applied if the entity corresponding to the If-Match value (a single
     828   applied if the representation corresponding to the If-Match value (a single
    828829   entity tag) is no longer a representation of that resource. This
    829830   allows the user to indicate that they do not wish the request to be
     
    955956</artwork></figure>
    956957<t>
    957    If any of the entity tags match the entity tag of the entity that
     958   If any of the entity tags match the entity tag of the representation that
    958959   would have been returned in the response to a similar GET request
    959960   (without the If-None-Match header) on that resource, or if "*" is
    960    given and any current entity exists for that resource, then the
     961   given and any current representation exists for that resource, then the
    961962   server &MUST-NOT; perform the requested method, unless required to do
    962963   so because the resource's modification date fails to match that
     
    964965   Instead, if the request method was GET or HEAD, the server &SHOULD;
    965966   respond with a 304 (Not Modified) response, including the cache-related
    966    header fields (particularly ETag) of one of the entities that
     967   header fields (particularly ETag) of one of the representations that
    967968   matched. For all other request methods, the server &MUST; respond with
    968969   a status of 412 (Precondition Failed).
     
    10871088</t>
    10881089<t>
    1089    An origin server &SHOULD; obtain the Last-Modified value of the entity
     1090   An origin server &SHOULD; obtain the Last-Modified value of the representation
    10901091   as close as possible to the time that it generates the Date value of
    10911092   its response. This allows a recipient to make an accurate assessment
    1092    of the entity's modification time, especially if the entity changes
     1093   of the entity's modification time, especially if the representation changes
    10931094   near the time that the response is generated.
    10941095</t>
Note: See TracChangeset for help on using the changeset viewer.