Ignore:
Timestamp:
Jul 22, 2010, 2:10:39 AM (10 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

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

    r863 r868  
    704704      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h2>
    705705      <p id="rfc.section.3.2.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This
    706          response code allows the client to place preconditions on the current resource metainformation (header field data) and thus
    707          prevent the requested method from being applied to a resource other than the one intended.
     706         response code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent
     707         the requested method from being applied to a resource other than the one intended.
    708708      </p>
    709709      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="weak.and.strong.validators" href="#weak.and.strong.validators">Weak and Strong Validators</a></h1>
    710       <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different entities,
    711          one normally would expect that if the entity (the entity-body or any entity-headers) changes in any way, then the associated
    712          validator would change as well. If this is true, then we call this validator a "strong validator."
     710      <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different representations,
     711         one normally would expect that if the representation (including both representation header fields and representation body)
     712         changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong
     713         validator."
    713714      </p>
    714715      <p id="rfc.section.4.p.2">However, there might be cases when a server prefers to change the validator only on semantically significant changes, and
    715          not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is
    716          a "weak validator."
     716         not when insignificant aspects of the representation change. A validator that does not always change when the representation
     717         changes is a "weak validator."
    717718      </p>
    718719      <p id="rfc.section.4.p.3">Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can
    719          think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever
    720          the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific
    721          entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
     720         think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value
     721         changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an
     722         identifier for a specific representation, whereas a weak validator is part of an identifier for a set of semantically equivalent
     723         representations.
    722724      </p>
    723725      <ul class="empty">
    724          <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
    725          </li>
    726          <li>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible
    727             that the resource might be modified twice during a single second.
     726         <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time a representation is changed.
     727         </li>
     728         <li>An entity's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible
     729            that the representation might be modified twice during a single second.
    728730         </li>
    729731         <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects;
     
    736738      </p>
    737739      <p id="rfc.section.4.p.5">Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality
    738          of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator
    739          is usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent entity.
     740         of a representation. For example, either kind is usable for a normal conditional GET. However, only a strong validator is
     741         usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent representation.
    740742      </p>
    741743      <p id="rfc.section.4.p.6">Clients <em class="bcp14">MUST NOT</em> use weak validators in range requests (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).
     
    795797      </p>
    796798      <ul>
    797          <li>The validator is being compared by an origin server to the actual current validator for the entity and,</li>
    798          <li>That origin server reliably knows that the associated entity did not change twice during the second covered by the presented
    799             validator.
     799         <li>The validator is being compared by an origin server to the actual current validator for the representation and,</li>
     800         <li>That origin server reliably knows that the associated representation did not change twice during the second covered by the
     801            presented validator.
    800802         </li>
    801803      </ul>
     
    803805      <ul>
    804806         <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has
    805             a cache entry for the associated entity, and
     807            a cache entry for the associated representation, and
    806808         </li>
    807809         <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
     
    810812      <p id="rfc.section.4.p.12">or </p>
    811813      <ul>
    812          <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and</li>
     814         <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation,
     815            and
     816         </li>
    813817         <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
    814818         <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li>
     
    892896      <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p>
    893897      <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    894          receives the entity.
     898         receives the message.
    895899      </p>
    896900      <div id="rfc.iref.e.1"></div>
     
    929933      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a>   = "If-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-match" class="smpl">If-Match-v</a>
    930934  <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    931 </pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
    932          request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
     935</pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar
     936         GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
    933937         then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    934938      </p>
    935       <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current entity exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
     939      <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
    936940         such as PUT, from modifying a resource that has changed since the client last retrieved it.
    937941      </p>
     
    941945      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
    942946      </p>
    943       <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.
    944          This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without
    945          their knowledge. Examples:
     947      <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity tag) is no longer a representation of
     948         that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been
     949         changed without their knowledge. Examples:
    946950      </p>
    947951      <div id="rfc.figure.u.10"></div><pre class="text">  If-Match: "xyzzy"
     
    10141018      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a>   = "If-None-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-none-match" class="smpl">If-None-Match-v</a>
    10151019  <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    1016 </pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
    1017          request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
    1018          then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied
    1019          in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the entities
     1020</pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar
     1021         GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists
     1022         for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied
     1023         in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the representations
    10201024         that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed).
    10211025      </p>
     
    10751079         last modification would indicate some time in the future, the server <em class="bcp14">MUST</em> replace that date with the message origination date.
    10761080      </p>
    1077       <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response.
    1078          This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes
    1079          near the time that the response is generated.
     1081      <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date value of
     1082         its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the
     1083         representation changes near the time that the response is generated.
    10801084      </p>
    10811085      <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.
Note: See TracChangeset for help on using the changeset viewer.