Ignore:
Timestamp:
19/01/13 13:53:26 (9 years ago)
Author:
fielding@…
Message:

Define time of evaluation along with precedence; remove more duplicate and conflicting requirements revealed by the addition of 428 (Precondition Required); reduce requirements targeting entity-tag to facts; clarify that servers only need to send validators on successful retrieval responses; addresses #350 and #427

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2105 r2128  
    209209</t>
    210210<t>
    211    A "strong validator" is a representation metadata value that &MUST; be
     211   A "strong validator" is a representation metadata value that is
    212212   changed to a new, previously unused or guaranteed unique, value whenever
    213213   a change occurs to the representation data such that a change would be
    … …  
    215215</t>
    216216<t>   
    217    A strong validator &MAY; be changed for other reasons, such as when a semantically
     217   A strong validator might change for other reasons, such as when a semantically
    218218   significant part of the representation metadata is changed (e.g.,
    219219   <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin
    220220   server to only change the value when it is necessary to invalidate the
    221221   stored responses held by remote caches and authoring tools.  A strong
    222    validator &MUST; be unique across all representations of a given resource,
     222   validator is unique across all representations of a given resource,
    223223   such that no two representations of that resource share the same validator
    224224   unless their payload body would be identical.
    … …  
    228228   of expiration times.  Thus, a cache might attempt to validate an
    229229   entry using a validator that it obtained in the distant past.
    230    A strong validator &MUST; be unique across all versions of all
     230   A strong validator is unique across all versions of all
    231231   representations associated with a particular resource over time.
    232232   However, there is no implication of uniqueness across representations
    … …  
    453453   for a representation and the generation of that entity-tag does not satisfy
    454454   the requirements for a strong validator
    455    (<xref target="weak.and.strong.validators"/>), then that
    456    entity-tag &MUST; be marked as weak by prefixing its opaque value
     455   (<xref target="weak.and.strong.validators"/>), then the origin server
     456   &MUST; mark the entity-tag as weak by prefixing its opaque value
    457457   with "W/" (case-sensitive).
    458458</t>
    … …  
    489489<section title="Comparison" anchor="entity.tag.comparison">
    490490  <x:anchor-alias value="validator.comparison"/>
     491  <x:anchor-alias value="strong comparison"/>
     492  <x:anchor-alias value="weak comparison"/>
    491493<t>
    492494   There are two entity-tag comparison functions, depending
    … …  
    494496   or not:
    495497  <list style="symbols">
    496      <t>The strong comparison function: in order to be considered equal,
    497         both opaque-tags &MUST; be identical character-by-character, and both
    498         &MUST-NOT; be weak.</t>
    499      <t>The weak comparison function: in order to be considered equal, both
    500         opaque-tags &MUST; be identical character-by-character, but
    501         either or both of them &MAY; be tagged as "weak" without affecting
    502         the result.</t>
     498     <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
     499        are not weak and their opaque-tags match character-by-character.</t>
     500     <t><x:dfn>Weak comparison</x:dfn>: two entity-tags are equivalent if their opaque-tags
     501        match character-by-character, regardless of either or both
     502        being tagged as "weak".</t>
    503503  </list>
    504504</t>
    … …  
    591591</section>
    592592
    593 <section title="Rules for When to Use Entity-tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">
     593<section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
    594594<t>
    595595   We adopt a set of rules and recommendations for origin servers,
    … …  
    598598</t>
    599599<t>
    600    HTTP/1.1 origin servers:
     600   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
    601601  <list style="symbols">
    602602     <t>&SHOULD; send an entity-tag validator unless it is not feasible to
    … …  
    612612</t>
    613613<t>
    614    In other words, the preferred behavior for an HTTP/1.1 origin server
    615    is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref> value.
    616 </t>
    617 <t>
    618    HTTP/1.1 clients:
     614   In other words, the preferred behavior for an origin server
     615   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref>
     616   value in successful responses to a retrieval request.
     617</t>
     618<t>
     619   A client:
    619620  <list style="symbols">
    620621     <t>&MUST; use that entity-tag in any cache-conditional request (using
    … …  
    638639  </list>
    639640</t>
    640 <t>
    641    An HTTP/1.1 origin server, upon receiving a conditional request that
    642    includes both a Last-Modified date (e.g., in an <x:ref>If-Modified-Since</x:ref>
    643    or <x:ref>If-Unmodified-Since</x:ref> header field) and one or more
    644    entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>,
    645    or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT;
    646    send a response status code of <x:ref>304 (Not Modified)</x:ref> unless
    647    doing so is consistent with all of the conditional header fields in the
    648    request.
    649 </t>
    650 <t>
    651    An HTTP/1.1 caching proxy, upon receiving a conditional request that
    652    includes both a Last-Modified date and one or more entity-tags as
    653    cache validators, &MUST-NOT; send a locally cached response to the
    654    client unless that cached response is consistent with all of the
    655    conditional header fields in the request.
    656   <list><t>
    657       &Note; The general principle behind these rules is that HTTP/1.1
    658       servers and clients ought to transmit as much non-redundant
    659       information as is available in their responses and requests.
    660       HTTP/1.1 systems receiving this information will make the most
    661       conservative assumptions about the validators they receive.
    662   </t><t>
    663       HTTP/1.0 clients and caches might ignore entity-tags. Generally,
    664       last-modified values received or used by these systems will
    665       support transparent and efficient caching, and so HTTP/1.1 origin
    666       servers still ought to provide Last-Modified values.
    667   </t></list>
    668 </t>
    669641</section>
    670642</section>
    … …  
    674646   This section defines the syntax and semantics of HTTP/1.1 header fields
    675647   for applying preconditions on requests.
    676    <xref target="precedence"/> defines the order of evaluation when
    677    more than one precondition is present in a request.
     648   <xref target="precedence"/> defines when the preconditions are applied and
     649   the order of evaluation when more than one precondition is present.
    678650</t>
    679651
    … …  
    705677</t>
    706678<t>
    707    If the condition is met, the server &MAY; perform the request method as if
    708    the If-Match header field was not present.
     679   If the condition is met, the server &MAY; perform the request method.
    709680</t>
    710681<t>
    … …  
    717688   &MUST-NOT; perform the requested method if the condition is not met;
    718689   instead, they &MUST; forward the request towards the origin server.
    719 </t>
    720 <t>
    721    If the request would, without the If-Match header field, result in
    722    anything other than a <x:ref>2xx (Successful)</x:ref> or <x:ref>412 (Precondition Failed)</x:ref>
    723    status code, then the If-Match header field &MUST; be ignored.
    724690</t>
    725691<t>
    … …  
    775741   selected representation that has a matching entity-tag. For all other
    776742   request methods, the server &MUST; respond with a <x:ref>412 (Precondition
    777    Failed)</x:ref> status code.
    778 </t>
    779 <t>
    780    If the condition is met, the server &MAY; perform the requested method
    781    as if the If-None-Match header field did not exist, but &MUST; also ignore
    782    any <x:ref>If-Modified-Since</x:ref> header field(s) in the request. That
    783    is, if no entity-tags match, then the server &MUST-NOT; send a <x:ref>304
    784    (Not Modified)</x:ref> response.
    785 </t>
    786 <t>
    787    If the request would, without the If-None-Match header field, result
    788    in anything other than a <x:ref>2xx (Successful)</x:ref> or
    789    <x:ref>304 (Not Modified)</x:ref> status code, then the If-None-Match
    790    header field &MUST; be ignored. (See <xref
    791    target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for
    792    a discussion of server behavior when both <x:ref>If-Modified-Since</x:ref>
    793    and If-None-Match appear in the same request.)
     743   Failed)</x:ref> status code when the condition is not met.
     744</t>
     745<t>
     746   If the condition is met, the server &MAY; perform the requested method and
     747   &MUST; ignore any <x:ref>If-Modified-Since</x:ref> header field(s) in the
     748   request. That is, if no entity-tags match, then the server &MUST-NOT; send
     749   a <x:ref>304 (Not Modified)</x:ref> response.
    794750</t>
    795751<t>
    … …  
    897853   respond with the <x:ref>412 (Precondition Failed)</x:ref> status code.
    898854   If the selected representation has not been modified since the time
    899    specified in this field, the server &SHOULD; perform the request
    900    method as if the If-Unmodified-Since header field were not present.
     855   specified in this field, the server &MAY; perform the request.
    901856</t>
    902857<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
    … …  
    910865</artwork></figure>
    911866<t>
    912    If a request normally (i.e., in absence of the If-Unmodified-Since
    913    header field) would result in anything other than a <x:ref>2xx (Successful)</x:ref>
    914    or <x:ref>412 (Precondition Failed)</x:ref> status code,
    915    the If-Unmodified-Since header field &SHOULD; be ignored.
    916 </t>
    917 <t>
    918    If the specified date is invalid, the header field &MUST; be ignored.
     867   A server &MUST; ignore the If-Unmodified-Since header field if the
     868   received value is not a valid HTTP-date.
    919869</t>
    920870</section>
    … …  
    982932  <x:anchor-alias value="412 (Precondition Failed)"/>
    983933<t>
    984    The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one or more preconditions given in
    985    the request header fields evaluated to false when tested on the server.
    986    This response code allows the client to place preconditions on the
    987    current resource state (its current representations and metadata)
    988    and thus prevent the request method from being applied if the target
    989    resource is in an unexpected state.
    990 </t>
    991 </section>
    992 </section>
    993 
    994 <section title="Precedence" anchor="precedence">
     934   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one
     935   or more preconditions given in the request header fields evaluated to false
     936   when tested on the server. This response code allows the client to place
     937   preconditions on the current resource state (its current representations
     938   and metadata) and thus prevent the request method from being applied if the
     939   target resource is in an unexpected state.
     940</t>
     941</section>
     942</section>
     943
     944<section title="Evaluation and Precedence" anchor="precedence">
     945<t>
     946   For each conditional request, a server &MUST; evaluate the request
     947   preconditions after it has successfully performed its normal request checks
     948   (i.e., just before it would perform the action associated with the request
     949   method). Preconditions are ignored if the server determines that an error
     950   or redirect response applies before they are evaluated.
     951</t>
    995952<t>
    996953   When more than one conditional request header field is present in a request,
    … …  
    999956   single, logical order, due to the fact that entity tags are presumed to be
    1000957   more accurate than date validators. For example, the only reason to send
    1001    both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in the same GET request is to
    1002    support intermediary caches that might not have implemented <x:ref>If-None-Match</x:ref>,
    1003    so it makes sense to ignore the <x:ref>If-Modified-Since</x:ref> when entity tags are
    1004    understood and available for the selected representation.
     958   both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in
     959   the same GET request is to support intermediary caches that might not have
     960   implemented <x:ref>If-None-Match</x:ref>, so it makes sense to ignore the
     961   <x:ref>If-Modified-Since</x:ref> when entity tags are understood and
     962   available for the selected representation.
    1005963</t>
    1006964<t>
Note: See TracChangeset for help on using the changeset viewer.