Ignore:
Timestamp:
28/03/11 14:15:02 (10 years ago)
Author:
fielding@…
Message:

Define "selected representation" as a shorthand for targeting
conditional requests, effectively replacing the old notion
of resource variants. Addresses #89.

Remove the nonsense about semantic equivalence and replace it
with the mechanical reason that origin servers might not want
to change a weak entity-tag on every update. Addresses #101.

Rewrite the condtional evaluation text accordingly and reduce
some duplication of requirements.

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r1215 r1223  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 28, 2011";
     361       content: "Expires September 29, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    406406      <meta name="dct.creator" content="Reschke, J. F.">
    407407      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    408       <meta name="dct.issued" scheme="ISO8601" content="2011-03-27">
     408      <meta name="dct.issued" scheme="ISO8601" content="2011-03-28">
    409409      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    410410      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    432432            </tr>
    433433            <tr>
    434                <td class="left">Expires: September 28, 2011</td>
     434               <td class="left">Expires: September 29, 2011</td>
    435435               <td class="right">J. Mogul</td>
    436436            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">March 27, 2011</td>
     491               <td class="right">March 28, 2011</td>
    492492            </tr>
    493493         </tbody>
    … …  
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire on September 28, 2011.</p>
     517      <p>This Internet-Draft will expire on September 29, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    604604         client.
    605605      </p>
    606       <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
     606      <p id="rfc.section.1.p.2">We use the term "selected representation" to refer to the current representation of the target resource that would have been
     607         selected and sent as payload in a 200 (OK) response if the same request had used the method GET and had excluded all of the
     608         conditional request header fields. The conditions found within conditional requests are evaluated on the basis of either the
     609         state of the target resource as a whole or the state of the target resource's selected representation.
     610      </p>
     611      <p id="rfc.section.1.p.3">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    607612         errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on
    608613         resource metadata will be discussed first and then followed by each conditional request header field, concluding with a definition
    … …  
    644649</pre><p id="rfc.section.2.p.3">A "strong entity-tag" <em class="bcp14">MAY</em> be shared by two representations of a resource only if they are equivalent by octet equality.
    645650      </p>
    646       <p id="rfc.section.2.p.4">A "weak entity-tag", indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource only if the representations are equivalent and could be substituted for each
    647          other with no significant change in semantics. A weak entity-tag can only be used for weak comparison.
    648       </p>
    649       <p id="rfc.section.2.p.5">An entity-tag <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource. A given entity-tag value <em class="bcp14">MAY</em> be used for representations obtained by requests on different URIs. The use of the same entity-tag value in conjunction with
    650          representations obtained by requests on different URIs does not imply the equivalence of those representations.
     651      <p id="rfc.section.2.p.4">A "weak entity-tag", indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource. A weak entity-tag can only be used for weak comparison.
     652      </p>
     653      <p id="rfc.section.2.p.5">Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it is inappropriate to expect
     654         that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. A
     655         strong entity-tag <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource over time. However, there is no
     656         implication of uniqueness across entity-tags of different resources (i.e., the same entity-tag value might be in use for representations
     657         of multiple resources at the same time and does not imply that those representations are equivalent).
    651658      </p>
    652659      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h2>
    … …  
    692699      <div id="rfc.iref.s.1"></div>
    693700      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h2>
    694       <p id="rfc.section.3.1.p.1">If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server <em class="bcp14">SHOULD</em> respond with this status code. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
     701      <p id="rfc.section.3.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a 200 (OK) response
     702         if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server to
     703         transfer a representation of the target resource because the client's request indicates that it already has a valid representation,
     704         as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation
     705         as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    695706      </p>
    696707      <p id="rfc.section.3.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) unless its omission is required by <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. If a 200 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag,
    … …  
    701712         cache updates (e.g., future HTTP extensions).
    702713      </p>
    703       <p id="rfc.section.3.1.p.4">If a 304 response includes an entity-tag that indicates a representation not currently cached, then the recipient <em class="bcp14">MUST NOT</em> use the 304 to update its own cache. If that conditional request originated with an outbound client, such as a user agent
    704          with its own cache sending a conditional GET to a shared proxy, then the 304 response <em class="bcp14">MAY</em> be forwarded to the outbound client. Otherwise, disregard the response and repeat the request without the conditional.
     714      <p id="rfc.section.3.1.p.4">If the recipient of a 304 response does not have a cached representation corresponding to the entity-tag indicated by the
     715         304 response, then the recipient <em class="bcp14">MUST NOT</em> use the 304 to update its own cache. If this conditional request originated with an outbound client, such as a user agent
     716         with its own cache sending a conditional GET to a shared proxy, then the 304 response <em class="bcp14">MAY</em> be forwarded to the outbound client. Otherwise, the recipient <em class="bcp14">MUST</em> disregard the 304 response and repeat the request without any preconditions.
    705717      </p>
    706718      <p id="rfc.section.3.1.p.5">If a cache uses a received 304 response to update a cache entry, the cache <em class="bcp14">MUST</em> update the entry to reflect any new field values given in the response.
    … …  
    709721      <div id="rfc.iref.s.2"></div>
    710722      <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>
    711       <p id="rfc.section.3.2.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server. This response
    712          code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent the requested
    713          method from being applied to a resource other than the one intended.
     723      <p id="rfc.section.3.2.p.1">The 412 status code indicates that one or more preconditions given in the request header fields evaluated to false when tested
     724         on the server. This response code allows the client to place preconditions on the current resource state (its current representations
     725         and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
    714726      </p>
    715727      <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>
    … …  
    717729         one normally would expect that if the representation (including both representation header fields and representation body)
    718730         changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong
    719          validator".
    720       </p>
    721       <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
    722          not when insignificant aspects of the representation change. A validator that does not always change when the representation
    723          changes is a "weak validator".
     731         validator". One example of a strong validator is an integer that is incremented in stable storage every time a representation
     732         is changed.
     733      </p>
     734      <p id="rfc.section.4.p.2">However, there might be cases when a server prefers to change the validator only when it desires cached representations to
     735         be invalidated. For example, the representation of a weather report that changes in content every second, based on dynamic
     736         measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) in order to
     737         allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load
     738         or weather quality). A validator that does not always change when the representation changes is a "weak validator".
    724739      </p>
    725740      <p id="rfc.section.4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak". One can
    726          think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value
    727          changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an
    728          identifier for a specific representation, whereas a weak validator is part of an identifier for a set of semantically equivalent
    729          representations.
     741         think of a strong validator as part of an identifier for a specific representation, whereas a weak validator is part of an
     742         identifier for a set of equivalent representations (where this notion of equivalence is entirely governed by the origin server
     743         and beyond the scope of this specification).
    730744      </p>
    731745      <ul class="empty">
    732          <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.
    733          </li>
    734746         <li>A representation's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible
    735747            that the representation might be modified twice during a single second.
    … …  
    740752         </li>
    741753      </ul>
    742       <p id="rfc.section.4.p.4">A "use" of a validator is either when a client generates a request and includes the validator in a validating header field,
     754      <p id="rfc.section.4.p.4">A strong entity-tag <em class="bcp14">MUST</em> change whenever the associated representation changes in any way. A weak entity-tag <em class="bcp14">SHOULD</em> change whenever the origin server considers prior representations to be unacceptable as a substitute for the current representation.
     755         In other words, a weak entity tag <em class="bcp14">SHOULD</em> change whenever the origin server wants caches to invalidate old responses.
     756      </p>
     757      <p id="rfc.section.4.p.5">A "use" of a validator is either when a client generates a request and includes the validator in a validating header field,
    743758         or when a server compares two validators.
    744759      </p>
    745       <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
     760      <p id="rfc.section.4.p.6">Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality
    746761         of a representation. For example, either kind is usable for a normal conditional GET. However, only a strong validator is
    747          usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent representation.
    748       </p>
    749       <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>).
     762         usable for range retrieval (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>), since otherwise the client might end up with an internally inconsistent representation. Clients <em class="bcp14">MUST NOT</em> use weak validators in range requests.
    750763      </p>
    751764      <p id="rfc.section.4.p.7">The only function that HTTP/1.1 defines on validators is comparison. There are two validator comparison functions, depending
    … …  
    848861            or if it is unfeasible to send a strong entity-tag.
    849862         </li>
    850          <li><em class="bcp14">SHOULD</em> send a Last-Modified value if it is feasible to send one, unless the risk of a breakdown in semantic transparency that could
    851             result from using this date in an If-Modified-Since header field would lead to serious problems.
     863         <li><em class="bcp14">SHOULD</em> send a Last-Modified value if it is feasible to send one.
    852864         </li>
    853865      </ul>
    … …  
    855867         value.
    856868      </p>
    857       <p id="rfc.section.5.p.4">In order to be legitimate, a strong entity-tag <em class="bcp14">MUST</em> change whenever the associated representation changes in any way. A weak entity-tag <em class="bcp14">SHOULD</em> change whenever the associated representation changes in a semantically significant way.
    858       </p>
    859       <div class="note" id="rfc.section.5.p.5">
    860          <p> <b>Note:</b> In order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity-tag value
    861             for two different representations, or reusing a specific weak entity-tag value for two semantically different representations.
    862             Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to
    863             expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the
    864             past.
    865          </p>
    866       </div>
    867       <p id="rfc.section.5.p.6">HTTP/1.1 clients: </p>
     869      <p id="rfc.section.5.p.4">HTTP/1.1 clients: </p>
    868870      <ul>
    869871         <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using If-Match or If-None-Match) if an entity-tag has been provided
    … …  
    880882         </li>
    881883      </ul>
    882       <p id="rfc.section.5.p.7">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
     884      <p id="rfc.section.5.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
    883885         or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header
    884886         field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields
    885887         in the request.
    886888      </p>
    887       <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
     889      <p id="rfc.section.5.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
    888890         as cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header
    889891         fields in the request.
    … …  
    926928      <div id="rfc.iref.h.2"></div>
    927929      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    928       <p id="rfc.section.6.2.p.1">The "If-Match" header field is used to make a request method conditional. A client that has one or more representations previously
    929          obtained from the resource can verify that one of those representations is current by including a list of their associated
    930          entity-tags in the If-Match header field.
    931       </p>
    932       <p id="rfc.section.6.2.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used when updating
    933          resources, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches
    934          any current representation of the resource.
     930      <p id="rfc.section.6.2.p.1">The "If-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on the current existence or value of an entity-tag for one or more representations
     931         of the target resource. If-Match is generally useful for resource update requests, such as PUT requests, as a means for protecting
     932         against accidental overwrites when multiple clients are acting in parallel on the same resource (i.e., the "lost update" problem).
     933         An If-Match field-value of "*" places the precondition on the existence of any current representation for the target resource.
    935934      </p>
    936935      <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>
    937936  <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    938 </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
    939          GET request (without the If-Match header field) on that resource, or if "*" is given and any current representation exists
    940          for that resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    941       </p>
    942       <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 request
    943          method, such as PUT, from modifying a resource that has changed since the client last retrieved it.
    944       </p>
    945       <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the
     937</pre><p id="rfc.section.6.2.p.3">If any of the entity-tags listed in the If-Match field value match the entity-tag of the selected representation for the target
     938         resource, or if "*" is given and any current representation exists for the target resource, then the server <em class="bcp14">MAY</em> perform the request method as if the If-Match header field was not present.
     939      </p>
     940      <p id="rfc.section.6.2.p.4">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. Instead, the server <em class="bcp14">MUST</em> respond with the 412 (Precondition Failed) status code.
     941      </p>
     942      <p id="rfc.section.6.2.p.5">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the
    946943         If-Match header field <em class="bcp14">MUST</em> be ignored.
    947944      </p>
    948       <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the request 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.
    949       </p>
    950       <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
    951          that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been
    952          changed without their knowledge. Examples:
    953       </p>
     945      <p id="rfc.section.6.2.p.6">Examples:</p>
    954946      <div id="rfc.figure.u.10"></div><pre class="text">  If-Match: "xyzzy"
    955947  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    956948  If-Match: *
    957 </pre><p id="rfc.section.6.2.p.10">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields
     949</pre><p id="rfc.section.6.2.p.8">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields
    958950         is undefined by this specification.
    959951      </p>
    … …  
    961953      <div id="rfc.iref.h.3"></div>
    962954      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
    963       <p id="rfc.section.6.3.p.1">The "If-Modified-Since" header field is used to make a request method conditional by date: if the representation that would
    964          have been transferred in a 200 response to a GET request has not been modified since the time specified in this field, then
    965          do not perform the method; instead, respond as detailed below.
     955      <p id="rfc.section.6.3.p.1">The "If-Modified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has not been modified since
     956         the time specified in this field, then do not perform the request method; instead, respond as detailed below.
    966957      </p>
    967958      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span>  <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>   = "If-Modified-Since" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    970961</pre><p id="rfc.section.6.3.p.3">An example of the field is:</p>
    971962      <div id="rfc.figure.u.12"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    972 </pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header field and no Range header field requests that the representation be transferred
    973          only if it has been modified since the date given by the If-Modified-Since header field. The algorithm for determining this
    974          includes the following cases:
     963</pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header field and no Range header field requests that the selected representation be
     964         transferred only if it has been modified since the date given by the If-Modified-Since header field. The algorithm for determining
     965         this includes the following cases:
    975966      </p>
    976967      <ol>
    … …  
    979970            invalid.
    980971         </li>
    981          <li>If the representation has been modified since the If-Modified-Since date, the response is exactly the same as for a normal
    982             GET.
    983          </li>
    984          <li>If the representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a 304 (Not Modified) response.
     972         <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for
     973            a normal GET.
     974         </li>
     975         <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a 304 (Not Modified) response.
    985976         </li>
    986977      </ol>
    … …  
    10111002      <div id="rfc.iref.h.4"></div>
    10121003      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2>
    1013       <p id="rfc.section.6.4.p.1">The "If-None-Match" header field is used to make a request method conditional. A client that has one or more representations
    1014          previously obtained from the resource can verify that none of those representations is current by including a list of their
    1015          associated entity-tags in the If-None-Match header field.
    1016       </p>
    1017       <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent
    1018          a request method (e.g., PUT) from inadvertently modifying an existing resource when the client believes that the resource
    1019          does not exist.
    1020       </p>
    1021       <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current representation of the resource.</p>
     1004      <p id="rfc.section.6.4.p.1">The "If-None-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on not matching any of the current entity-tag values for representations of the
     1005         target resource. If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information
     1006         with a minimum amount of transaction overhead. A client that has one or more representations previously obtained from the
     1007         target resource can send If-None-Match with a list of the associated entity-tags in the hope of receiving a 304 response if
     1008         at least one of those representations matches the selected representation.
     1009      </p>
     1010      <p id="rfc.section.6.4.p.2">If-None-Match MAY also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying
     1011         an existing representation of the target resource when the client believes that the resource does not have a current representation.
     1012         This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation
     1013         for the target resource.
     1014      </p>
    10221015      <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>
    10231016  <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    1024 </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
    1025          GET request (without the If-None-Match header field) on that resource, or if "*" is given and any current representation exists
    1026          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
    1027          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
    1028          that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed) status code.
    1029       </p>
    1030       <p id="rfc.section.6.4.p.6">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
    1031       </p>
    1032       <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then
     1017</pre><p id="rfc.section.6.4.p.4">If any of the entity-tags listed in the If-None-Match field-value match the entity-tag of the selected representation, or
     1018         if "*" is given and any current representation exists for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) status code, including the cache-related header fields (particularly ETag) of the selected
     1019         representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed) status code.
     1020      </p>
     1021      <p id="rfc.section.6.4.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
     1022      </p>
     1023      <p id="rfc.section.6.4.p.6">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then
    10331024         the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    10341025      </p>
    1035       <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the request method <em class="bcp14">MUST NOT</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.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
    1036       </p>
    1037       <p id="rfc.section.6.4.p.9">Examples:</p>
     1026      <p id="rfc.section.6.4.p.7">Examples:</p>
    10381027      <div id="rfc.figure.u.14"></div><pre class="text">  If-None-Match: "xyzzy"
    10391028  If-None-Match: W/"xyzzy"
    … …  
    10411030  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
    10421031  If-None-Match: *
    1043 </pre><p id="rfc.section.6.4.p.11">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header
     1032</pre><p id="rfc.section.6.4.p.9">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header
    10441033         fields is undefined by this specification.
    10451034      </p>
    … …  
    10471036      <div id="rfc.iref.h.5"></div>
    10481037      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    1049       <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" header field is used to make a request method conditional. If the representation that would have
    1050          been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified in
    1051          this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header field were not present.
    1052       </p>
    1053       <p id="rfc.section.6.5.p.2">If the representation has been modified since the specified time, the server <em class="bcp14">MUST NOT</em> perform the requested operation, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed).
     1038      <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has been modified since
     1039         the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the 412 (Precondition Failed) status code. If the selected representation has not been modified since
     1040         the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present.
    10541041      </p>
    10551042      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>   = "If-Unmodified-Since" ":" <a href="#core.rules" class="smpl">OWS</a>
    10561043                          <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since-v</a>
    10571044  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since-v</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    1058 </pre><p id="rfc.section.6.5.p.4">An example of the field is:</p>
     1045</pre><p id="rfc.section.6.5.p.3">An example of the field is:</p>
    10591046      <div id="rfc.figure.u.16"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1060 </pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header field) would result in anything other than a 2xx or
     1047</pre><p id="rfc.section.6.5.p.5">If the request normally (i.e., without the If-Unmodified-Since header field) would result in anything other than a 2xx or
    10611048         412 status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
    10621049      </p>
    1063       <p id="rfc.section.6.5.p.7">If the specified date is invalid, the header field is ignored.</p>
    1064       <p id="rfc.section.6.5.p.8">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since
     1050      <p id="rfc.section.6.5.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored.
     1051      </p>
     1052      <p id="rfc.section.6.5.p.7">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since
    10651053         header fields is undefined by this specification.
    10661054      </p>
    … …  
    14741462                     </ul>
    14751463                  </li>
    1476                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">6.2</a>, <a href="#rfc.xref.Part6.3">6.4</a>, <a href="#Part6"><b>10.1</b></a><ul>
    1477                         <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">6.2</a>, <a href="#rfc.xref.Part6.3">6.4</a></li>
    1478                      </ul>
    1479                   </li>
     1464                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#Part6"><b>10.1</b></a></li>
    14801465               </ul>
    14811466            </li>

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

    r1180 r1223  
    225225</t>
    226226<t>
     227   We use the term "selected representation" to refer to the current
     228   representation of the target resource that would have been selected
     229   and sent as payload in a 200 (OK) response if the same request had used
     230   the method GET and had excluded all of the conditional request header
     231   fields.  The conditions found within conditional requests are evaluated
     232   on the basis of either the state of the target resource as a whole or
     233   the state of the target resource's selected representation.
     234</t>
     235<t>
    227236   This document is currently disorganized in order to minimize the changes
    228237   between drafts and enable reviewers to see the smaller errata changes.
    … …  
    329338<t>
    330339   A "weak entity-tag", indicated by the "W/" prefix, &MAY; be shared by
    331    two representations of a resource only if the representations are equivalent and
    332    could be substituted for each other with no significant change in
    333    semantics. A weak entity-tag can only be used for weak comparison.
    334 </t>
    335 <t>
    336    An entity-tag &MUST; be unique across all versions of all representations
    337    associated with a particular resource. A given entity-tag value &MAY;
    338    be used for representations obtained by requests on different URIs. The use
    339    of the same entity-tag value in conjunction with representations obtained by
    340    requests on different URIs does not imply the equivalence of those
    341    representations.
     340   two representations of a resource. A weak entity-tag can only be used
     341   for weak comparison.
     342</t>
     343<t>
     344   Cache entries might persist for arbitrarily long periods, regardless
     345   of expiration times, so it is inappropriate to expect that a cache will
     346   never again attempt to validate an entry using a validator that it
     347   obtained at some point in the past.
     348   A strong entity-tag &MUST; be unique across all versions of all
     349   representations associated with a particular resource over time.
     350   However, there is no implication of uniqueness across entity-tags
     351   of different resources (i.e., the same entity-tag value might be
     352   in use for representations of multiple resources at the same time
     353   and does not imply that those representations are equivalent).
    342354</t>
    343355
    … …  
    402414  <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
    403415<t>
    404    If the client has performed a conditional GET request and access is
    405    allowed, but the document has not been modified, the server &SHOULD;
    406    respond with this status code. The 304 response &MUST-NOT; contain a
    407    message-body, and thus is always terminated by the first empty line
    408    after the header fields.
     416   The 304 status code indicates that a conditional GET request has been
     417   received and would have resulted in a 200 (OK) response if it were not
     418   for the fact that the condition has evaluated to false.  In other words,
     419   there is no need for the server to transfer a representation of the
     420   target resource because the client's request indicates that it already
     421   has a valid representation, as indicated by the 304 response header
     422   fields, and is therefore redirecting the client to make use of that
     423   stored representation as if it were the payload of a 200 response.
     424   The 304 response &MUST-NOT; contain a message-body, and thus is always
     425   terminated by the first empty line after the header fields.
    409426</t>
    410427<t>
    … …  
    423440</t>
    424441<t>
    425    If a 304 response includes an entity-tag that indicates a
    426    representation not currently cached, then the recipient &MUST-NOT;
    427    use the 304 to update its own cache.  If that conditional request originated
    428    with an outbound client, such as a user agent with its own cache sending a
    429    conditional GET to a shared proxy, then the 304 response &MAY; be
    430    forwarded to the outbound client.  Otherwise, disregard the response
    431    and repeat the request without the conditional.
     442   If the recipient of a 304 response does not have a cached representation
     443   corresponding to the entity-tag indicated by the 304 response, then the
     444   recipient &MUST-NOT; use the 304 to update its own cache.  If this
     445   conditional request originated with an outbound client, such as a
     446   user agent with its own cache sending a conditional GET to a shared
     447   proxy, then the 304 response &MAY; be forwarded to the outbound client.
     448   Otherwise, the recipient &MUST; disregard the 304 response and repeat
     449   the request without any preconditions.
    432450</t>
    433451<t>
    … …  
    442460  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
    443461<t>
    444    The precondition given in one or more of the header fields
    445    evaluated to false when it was tested on the server. This response
    446    code allows the client to place preconditions on the current resource
    447    metadata (header field data) and thus prevent the requested
    448    method from being applied to a resource other than the one intended.
     462   The 412 status code indicates that one or more preconditions given in
     463   the request header fields evaluated to false when tested on the server.
     464   This response code allows the client to place preconditions on the
     465   current resource state (its current representations and metadata)
     466   and thus prevent the request method from being applied if the target
     467   resource is in an unexpected state.
    449468</t>
    450469</section>
    … …  
    454473<t>
    455474   Since both origin servers and caches will compare two validators to
    456    decide if they represent the same or different representations, one normally
    457    would expect that if the representation (including both representation
    458    header fields and representation body) changes in any way, then the
    459    associated validator would change as well. If this is true, then we
    460    call this validator a "strong validator".
     475   decide if they represent the same or different representations, one
     476   normally would expect that if the representation (including both
     477   representation header fields and representation body) changes in any
     478   way, then the associated validator would change as well. If this is
     479   true, then we call this validator a "strong validator".  One example
     480   of a strong validator is an integer that is incremented in stable
     481   storage every time a representation is changed.
    461482</t>
    462483<t>
    463484   However, there might be cases when a server prefers to change the
    464    validator only on semantically significant changes, and not when
    465    insignificant aspects of the representation change. A validator that does not
    466    always change when the representation changes is a "weak validator".
     485   validator only when it desires cached representations to be invalidated.
     486   For example, the representation of a weather report that changes in
     487   content every second, based on dynamic measurements, might be grouped
     488   into sets of equivalent representations (from the origin server's
     489   perspective) in order to allow cached representations to be valid
     490   for a reasonable period of time (perhaps adjusted dynamically based
     491   on server load or weather quality).
     492   A validator that does not always change when the representation
     493   changes is a "weak validator".
    467494</t>
    468495<t>
    469496   An entity-tag is normally a strong validator, but the protocol
    470    provides a mechanism to tag an entity-tag as "weak". One can think of
    471    a strong validator as one that changes whenever the sequence of bits
    472    in a representation changes, while a weak value changes whenever the
    473    meaning of a representation changes. Alternatively, one can think of
    474    a strong validator as part of an identifier for a specific representation,
    475    whereas a weak validator is part of an identifier for a set of semantically
    476    equivalent representations.
     497   provides a mechanism to tag an entity-tag as "weak". One can think
     498   of a strong validator as part of an identifier for a specific
     499   representation, whereas a weak validator is part of an identifier
     500   for a set of equivalent representations (where this notion of
     501   equivalence is entirely governed by the origin server and beyond
     502   the scope of this specification).
    477503  <list><t>
    478       <x:h>Note:</x:h> One example of a strong validator is an integer that is
    479       incremented in stable storage every time a representation is changed.
    480     </t><t>
    481504      A representation's modification time, if defined with only one-second
    482505      resolution, could be a weak validator, since it is possible that
    … …  
    491514</t>
    492515<t>
     516   A strong entity-tag &MUST; change whenever the associated representation
     517   changes in any way. A weak entity-tag &SHOULD; change whenever the origin
     518   server considers prior representations to be unacceptable as a substitute
     519   for the current representation. In other words, a weak entity tag &SHOULD;
     520   change whenever the origin server wants caches to invalidate old responses.
     521</t>
     522<t>
    493523   A "use" of a validator is either when a client generates a request
    494524   and includes the validator in a validating header field, or when a
    … …  
    499529   usable in contexts that do not depend on exact equality of a representation.
    500530   For example, either kind is usable for a normal conditional GET.
    501    However, only a strong validator is usable for a sub-range
    502    retrieval, since otherwise the client might end up with an internally
    503    inconsistent representation.
    504 </t>
    505 <t>
    506    Clients &MUST-NOT; use weak validators in range requests (<xref target="Part5"/>).
     531   However, only a strong validator is usable for range retrieval
     532   (<xref target="Part5"/>), since otherwise the client might end up
     533   with an internally inconsistent representation.
     534   Clients &MUST-NOT; use weak validators in range requests.
    507535</t>
    508536<t>
    … …  
    635663        or if it is unfeasible to send a strong entity-tag.</t>
    636664
    637      <t>&SHOULD; send a Last-Modified value if it is feasible to send one,
    638         unless the risk of a breakdown in semantic transparency that
    639         could result from using this date in an If-Modified-Since header
    640         field would lead to serious problems.</t>
     665     <t>&SHOULD; send a Last-Modified value if it is feasible to send one.</t>
    641666  </list>
    642667</t>
    … …  
    645670   is to send both a strong entity-tag and a Last-Modified value.
    646671</t>
    647 <t>
    648    In order to be legitimate, a strong entity-tag &MUST; change whenever the
    649    associated representation changes in any way. A weak entity-tag &SHOULD;
    650    change whenever the associated representation changes in a semantically
    651    significant way.
    652 </t>
    653 <x:note>
    654   <t>
    655     <x:h>Note:</x:h> In order to provide semantically transparent caching, an
    656     origin server must avoid reusing a specific strong entity-tag
    657     value for two different representations, or reusing a specific weak
    658     entity-tag value for two semantically different representations. Cache
    659     entries might persist for arbitrarily long periods, regardless of
    660     expiration times, so it might be inappropriate to expect that a
    661     cache will never again attempt to validate an entry using a
    662     validator that it obtained at some point in the past.
    663   </t>
    664 </x:note>
    665672<t>
    666673   HTTP/1.1 clients:
    … …  
    774781  <x:anchor-alias value="If-Match-v"/>
    775782<t>
    776    The "If-Match" header field is used to make a request method
    777    conditional. A client that has one or more representations previously
    778    obtained from the resource can verify that one of those representations is
    779    current by including a list of their associated entity-tags in the
    780    If-Match header field.
    781 </t>
    782 <t>
    783    This allows efficient updates of cached information with a minimum amount of
    784    transaction overhead. It is also used when updating resources, to prevent
    785    inadvertent modification of the wrong version of a resource. As a special
    786    case, the value "*" matches any current representation of the resource.
     783   The "If-Match" header field &MAY; be used to make a request method
     784   conditional on the current existence or value of an entity-tag for
     785   one or more representations of the target resource.  If-Match is
     786   generally useful for resource update requests, such as PUT requests,
     787   as a means for protecting against accidental overwrites when multiple
     788   clients are acting in parallel on the same resource (i.e., the
     789   "lost update" problem).  An If-Match field-value of "*" places the
     790   precondition on the existence of any current representation for the
     791   target resource.
    787792</t>
    788793<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/><iref primary="true" item="Grammar" subitem="If-Match-v"/>
    … …  
    791796</artwork></figure>
    792797<t>
    793    If any of the entity-tags match the entity-tag of the representation that
    794    would have been returned in the response to a similar GET request
    795    (without the If-Match header field) on that resource, or if "*" is given
    796    and any current representation exists for that resource, then the server &MAY;
    797    perform the requested method as if the If-Match header field did not
    798    exist.
     798   If any of the entity-tags listed in the If-Match field value match
     799   the entity-tag of the selected representation for the target resource,
     800   or if "*" is given and any current representation exists for the
     801   target resource, then the server &MAY; perform the request method
     802   as if the If-Match header field was not present.
    799803</t>
    800804<t>
    801805   If none of the entity-tags match, or if "*" is given and no current
    802    representation exists, the server &MUST-NOT; perform the requested method, and
    803    &MUST; return a 412 (Precondition Failed) response. This behavior is
    804    most useful when the client wants to prevent an updating request method,
    805    such as PUT, from modifying a resource that has changed since the client
    806    last retrieved it.
     806   representation exists, the server &MUST-NOT; perform the requested method.
     807   Instead, the server &MUST; respond with the 412 (Precondition Failed)
     808   status code.
    807809</t>
    808810<t>
    … …  
    812814</t>
    813815<t>
    814    The meaning of "If-Match: *" is that the request method &SHOULD; be performed
    815    if the representation selected by the origin server (or by a cache,
    816    possibly using the Vary mechanism, see &header-vary;) exists, and
    817    &MUST-NOT; be performed if the representation does not exist.
    818 </t>
    819 <t>
    820    A request intended to update a resource (e.g., a PUT) &MAY; include an
    821    If-Match header field to signal that the request method &MUST-NOT; be
    822    applied if the representation corresponding to the If-Match value (a single
    823    entity-tag) is no longer a representation of that resource. This
    824    allows the user to indicate that they do not wish the request to be
    825    successful if the resource has been changed without their knowledge.
    826816   Examples:
    827817</t>
    … …  
    844834  <x:anchor-alias value="If-Modified-Since-v"/>
    845835<t>
    846    The "If-Modified-Since" header field is used to make a request
    847    method conditional by date: if the representation that would have been
    848    transferred in a 200 response to a GET request has not been modified since
    849    the time specified in this field, then do not perform the method;
    850    instead, respond as detailed below.
     836   The "If-Modified-Since" header field &MAY; be used to make a request
     837   method conditional by modification date: if the selected representation
     838   has not been modified since the time specified in this field, then
     839   do not perform the request method; instead, respond as detailed below.
    851840</t>
    852841<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><iref primary="true" item="Grammar" subitem="If-Modified-Since-v"/>
    … …  
    863852<t>
    864853   A GET method with an If-Modified-Since header field and no Range header
    865    field requests that the representation be transferred only if it has
    866    been modified since the date given by the If-Modified-Since header field.
     854   field requests that the selected representation be transferred only if
     855   it has been modified since the date given by the If-Modified-Since
     856   header field.
    867857   The algorithm for determining this includes the following cases:
    868858  <list style="numbers">
    … …  
    873863         invalid.</t>
    874864
    875       <t>If the representation has been modified since the If-Modified-Since
    876          date, the response is exactly the same as for a normal GET.</t>
    877 
    878       <t>If the representation has not been modified since a valid
     865      <t>If the selected representation has been modified since the
     866         If-Modified-Since date, the response is exactly the same as for
     867         a normal GET.</t>
     868
     869      <t>If the selected representation has not been modified since a valid
    879870         If-Modified-Since date, the server &SHOULD; return a
    880871         304 (Not Modified) response.</t>
    … …  
    929920  <x:anchor-alias value="If-None-Match-v"/>
    930921<t>
    931    The "If-None-Match" header field is used to make a request method
    932    conditional. A client that has one or more representations previously
    933    obtained from the resource can verify that none of those representations is
    934    current by including a list of their associated entity-tags in the
    935    If-None-Match header field.
    936 </t>
    937 <t>
    938    This allows efficient updates of cached information with a minimum amount of
    939    transaction overhead. It is also used to prevent a request method (e.g., PUT)
    940    from inadvertently modifying an existing resource when the client
    941    believes that the resource does not exist.
    942 </t>
    943 <t>
    944    As a special case, the value "*" matches any current representation of the
    945    resource.
     922   The "If-None-Match" header field &MAY; be used to make a request method
     923   conditional on not matching any of the current entity-tag values for
     924   representations of the target resource.  If-None-Match is primarily
     925   used in conditional GET requests to enable efficient updates of cached
     926   information with a minimum amount of transaction overhead.  A client
     927   that has one or more representations previously obtained from the
     928   target resource can send If-None-Match with a list of the associated
     929   entity-tags in the hope of receiving a 304 response if at least one
     930   of those representations matches the selected representation.
     931</t>
     932<t>
     933   If-None-Match MAY also be used with a value of "*" to prevent an unsafe
     934   request method (e.g., PUT) from inadvertently modifying an existing
     935   representation of the target resource when the client believes that
     936   the resource does not have a current representation.  This is a variation
     937   on the "lost update" problem that might arise if more than one client
     938   attempts to create an initial representation for the target resource.
    946939</t>
    947940<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/><iref primary="true" item="Grammar" subitem="If-None-Match-v"/>
    … …  
    950943</artwork></figure>
    951944<t>
    952    If any of the entity-tags match the entity-tag of the representation that
    953    would have been returned in the response to a similar GET request
    954    (without the If-None-Match header field) on that resource, or if "*" is
     945   If any of the entity-tags listed in the If-None-Match field-value match
     946   the entity-tag of the selected representation, or if "*" is
    955947   given and any current representation exists for that resource, then the
    956    server &MUST-NOT; perform the requested method, unless required to do
    957    so because the resource's modification date fails to match that
    958    supplied in an If-Modified-Since header field in the request.
     948   server &MUST-NOT; perform the requested method.
    959949   Instead, if the request method was GET or HEAD, the server &SHOULD;
    960    respond with a 304 (Not Modified) response, including the cache-related
    961    header fields (particularly ETag) of one of the representations that
    962    matched. For all other request methods, the server &MUST; respond with
    963    a 412 (Precondition Failed) status code.
     950   respond with a 304 (Not Modified) status code, including the cache-related
     951   header fields (particularly ETag) of the selected representation that has
     952   a matching entity-tag.  For all other request methods, the server &MUST;
     953   respond with a 412 (Precondition Failed) status code.
    964954</t>
    965955<t>
    … …  
    973963   If the request would, without the If-None-Match header field, result
    974964   in anything other than a 2xx or 304 status code, then the If-None-Match
    975    header field &MUST; be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of
    976    server behavior when both If-Modified-Since and If-None-Match appear
    977    in the same request.)
    978 </t>
    979 <t>
    980    The meaning of "If-None-Match: *" is that the request method &MUST-NOT; be
    981    performed if the representation selected by the origin server (or by
    982    a cache, possibly using the Vary mechanism, see &header-vary;)
    983    exists, and &SHOULD; be performed if the representation does not exist.
    984    This feature is intended to be useful in preventing races between PUT
    985    operations.
     965   header field &MUST; be ignored. (See <xref
     966   target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for
     967   a discussion of server behavior when both If-Modified-Since and
     968   If-None-Match appear in the same request.)
    986969</t>
    987970<t>
    … …  
    1008991  <x:anchor-alias value="If-Unmodified-Since-v"/>
    1009992<t>
    1010    The "If-Unmodified-Since" header field is used to make a request
    1011    method conditional.  If the representation that would have been transferred
    1012    in a 200 response to a GET request on the same resource has not been modified
    1013    since the time specified in this field, the server &SHOULD; perform the
    1014    requested operation as if the If-Unmodified-Since header field were not
    1015    present.
    1016 </t>
    1017 <t>
    1018    If the representation has been modified since the specified time,
    1019    the server &MUST-NOT; perform the requested operation, and &MUST; return
    1020    a 412 (Precondition Failed).
     993   The "If-Unmodified-Since" header field &MAY; be used to make a request
     994   method conditional by modification date: if the selected representation
     995   has been modified since the time specified in this field, then the
     996   server &MUST-NOT; perform the requested operation and &MUST; instead
     997   respond with the 412 (Precondition Failed) status code.
     998   If the selected representation has not been modified since the time
     999   specified in this field, the server &SHOULD; perform the request
     1000   method as if the If-Unmodified-Since header field were not present.
    10211001</t>
    10221002<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/><iref primary="true" item="Grammar" subitem="If-Unmodified-Since-v"/>
    … …  
    10371017</t>
    10381018<t>
    1039    If the specified date is invalid, the header field is ignored.
     1019   If the specified date is invalid, the header field &MUST; be ignored.
    10401020</t>
    10411021<t>
Note: See TracChangeset for help on using the changeset viewer.