Ignore:
Timestamp:
Mar 28, 2011, 7:15:02 AM (8 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.

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.