Changeset 2355


Ignore:
Timestamp:
Aug 11, 2013, 3:20:11 AM (6 years ago)
Author:
fielding@…
Message:

Rephrase If-Match and If-Unmodified-Since, again, to describe how a cache is supposed to evaluate them; addresses part of #479

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

Legend:

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

    r2354 r2355  
    449449  }
    450450  @bottom-center {
    451        content: "Expires February 11, 2014";
     451       content: "Expires February 12, 2014";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-08-10">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-08-11">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
     
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: February 11, 2014</td>
    520                <td class="right">August 10, 2013</td>
     519               <td class="left">Expires: February 12, 2014</td>
     520               <td class="right">August 11, 2013</td>
    521521            </tr>
    522522         </tbody>
     
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on February 11, 2014.</p>
     547      <p>This Internet-Draft will expire on February 12, 2014.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    937937      <div id="rfc.iref.i.1"></div>
    938938      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    939       <p id="rfc.section.3.1.p.1">The "If-Match" header field can be used to make a request method conditional on the current existence or value of an entity-tag
    940          for one or more representations of the target resource.
    941       </p>
    942       <p id="rfc.section.3.1.p.2">If-Match is generally useful for resource update requests, such as PUT requests, as a means for protecting against accidental
    943          overwrites when multiple clients are acting in parallel on the same resource (i.e., the "lost update" problem). An If-Match
    944          field-value of "*" places the precondition on the existence of any current representation for the target resource.
     939      <p id="rfc.section.3.1.p.1">The "If-Match" header field makes the request method conditional on either the existence of a current representation for the
     940         target resource, when the field-value is "*", or on the selected representation having an entity-tag that matches one of those
     941         provided in the field-value.
    945942      </p>
    946943      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
    947 </pre><p id="rfc.section.3.1.p.4">The If-Match condition is met if and only if any of the entity-tags listed in the If-Match field value match the entity-tag
    948          of the selected representation using the weak comparison function (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>), or if "*" is given and any current representation exists for the target resource.
    949       </p>
    950       <p id="rfc.section.3.1.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method.
    951       </p>
    952       <p id="rfc.section.3.1.p.6">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
    953          in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
    954          agent might not be aware of that due to the prior response message being lost or because a compatible change was made by some
    955          other user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a> status code unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.
    956       </p>
    957       <p id="rfc.section.3.1.p.7">A proxy using a cached response as the selected representation <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead, the proxy <em class="bcp14">MUST</em> forward the request towards the origin server.
    958       </p>
    959       <p id="rfc.section.3.1.p.8">Examples:</p>
     944</pre><p id="rfc.section.3.1.p.3">Examples:</p>
    960945      <div id="rfc.figure.u.9"></div><pre class="text">  If-Match: "xyzzy"
    961946  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    962947  If-Match: *
    963 </pre><div id="rfc.iref.i.2"></div>
     948</pre><p id="rfc.section.3.1.p.5">If the request semantics (method and header fields) allow the request to be satisfied with a cached response, a cache <em class="bcp14">SHOULD</em> evaluate the condition based on its currently stored set of suitable responses for that request (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the field-value is "*" and any suitable response is currently stored, or if the field-value is a list of entity-tag
     949         values and at least one of the suitable responses has an <a href="#header.etag" class="smpl">ETag</a> header field with a value matching an entity-tag in that list, then the cache <em class="bcp14">SHOULD</em> reuse the most suitable of those matching responses to satisfy the request. If the condition is not met, none of the cached
     950         responses is suitable for reuse in response to this request.
     951      </p>
     952      <p id="rfc.section.3.1.p.6">If the request semantics cannot be satisfied with a cached response, the conditional is only evaluated when received by an
     953         origin server. For example, If-Match is most often used with state-changing requests, such as PUT, to prevent accidental overwrites
     954         when multiple user agents might be acting in parallel on the same resource (i.e., to prevent the "lost update" problem).
     955      </p>
     956      <p id="rfc.section.3.1.p.7">When the If-Match field-value consists of a list of entity-tag values, the condition is met if any of the entity-tags listed
     957         match, using the weak comparison function (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>), the entity-tag of the selected representation. When the If-Match field-value is "*", the condition is met if any current
     958         representation exists for the target resource.
     959      </p>
     960      <p id="rfc.section.3.1.p.8">If the condition is met, the origin server <em class="bcp14">MAY</em> perform the requested method.
     961      </p>
     962      <p id="rfc.section.3.1.p.9">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
     963         in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
     964         agent might not be aware of that because the prior response message was lost or a compatible change was made by some other
     965         user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior
     966         change made by the same user agent.
     967      </p>
     968      <div id="rfc.iref.i.2"></div>
    964969      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2>
    965970      <p id="rfc.section.3.2.p.1">The "If-None-Match" header field can be used to make a request method conditional on not matching any of the current entity-tag
     
    10331038      <div id="rfc.iref.i.4"></div>
    10341039      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    1035       <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field can be used to make a request method conditional by modification date: if the selected
    1036          representation has not been modified since the time specified in this field, then the condition is met. If-Unmodified-Since
    1037          is useful for resource update requests, when the resource does not provide entity-tag values, as a means for protecting against
    1038          accidental overwrites when multiple clients are acting in parallel on the same resource (i.e., the "lost update" problem).
     1040      <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field makes the request method conditional on the selected representation's last modification
     1041         date being earlier or equal to the date provided in the field-value. This field accomplishes the same purpose as <a href="#header.if-match" class="smpl">If-Match</a> for cases where the user agent does not have an entity-tag for the representation.
    10391042      </p>
    10401043      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    10411044</pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
    10421045      <div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1043 </pre><p id="rfc.section.3.4.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method.
    1044       </p>
    1045       <p id="rfc.section.3.4.p.6">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
     1046</pre><p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the selected representation has an entity-tag and the request contains an If-Match header field;
     1047         the condition in If-Match, when applicable, is considered to be a more accurate replacement for the condition in If-Unmodified-Since.
     1048      </p>
     1049      <p id="rfc.section.3.4.p.6">A server <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received field-value is not a valid HTTP-date.
     1050      </p>
     1051      <p id="rfc.section.3.4.p.7">If the request semantics (method and header fields) allow the request to be satisfied with a cached response, a cache <em class="bcp14">SHOULD</em> evaluate the condition based on its currently stored set of suitable responses for that request (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the most suitable response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> date that is earlier or equal to the date given in If-Unmodified-Since, the cache <em class="bcp14">SHOULD</em> reuse that response to satisfy the request. If the condition is not met, none of the stored responses is suitable for reuse
     1052         in response to this request.
     1053      </p>
     1054      <p id="rfc.section.3.4.p.8">If the request semantics cannot be satisfied with a cached response, the conditional is only evaluated when received by an
     1055         origin server. If the selected representation has not been modified since the time specified in this field, then the condition
     1056         is met.
     1057      </p>
     1058      <p id="rfc.section.3.4.p.9">If the condition is met, the origin server <em class="bcp14">MAY</em> perform the requested method.
     1059      </p>
     1060      <p id="rfc.section.3.4.p.10">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
    10461061         in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
    1047          agent might not be aware of that due to the prior response message being lost or because a compatible change was made by some
    1048          other user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a> status code unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.
    1049       </p>
    1050       <p id="rfc.section.3.4.p.7">A proxy using a cached response as the selected representation <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead, the proxy <em class="bcp14">MUST</em> forward the request towards the origin server.
    1051       </p>
    1052       <p id="rfc.section.3.4.p.8">A server <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received value is not a valid HTTP-date.
     1062         agent might not be aware of that because the prior response message was lost or a compatible change was made by some other
     1063         user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior
     1064         change made by the same user agent.
    10531065      </p>
    10541066      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
     
    10691081         cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field).
    10701082      </p>
    1071       <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
     1083      <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
    10721084         GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client.
    10731085      </p>
     
    15161528                     </ul>
    15171529                  </li>
    1518                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">4.1</a>, <a href="#Part6"><b>9.1</b></a><ul>
    1519                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">4.1</a></li>
     1530                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">4.1</a>, <a href="#Part6"><b>9.1</b></a><ul>
     1531                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.4</a></li>
     1532                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">4.1</a></li>
    15201533                     </ul>
    15211534                  </li>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2354 r2355  
    2929  <!ENTITY semantics                  "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3030  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     31  <!ENTITY cache-key                  "<xref target='Part6' x:rel='#constructing.responses.from.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3132  <!ENTITY freshening-responses       "<xref target='Part6' x:rel='#freshening.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3233  <!ENTITY header-accept-encoding     "<xref target='Part2' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    661662  <x:anchor-alias value="If-Match"/>
    662663<t>
    663    The "If-Match" header field can be used to make a request method conditional
    664    on the current existence or value of an entity-tag for one or more
    665    representations of the target resource.
    666 </t>
    667 <t>
    668    If-Match is generally useful for resource update requests, such as PUT
    669    requests, as a means for protecting against accidental overwrites when
    670    multiple clients are acting in parallel on the same resource (i.e., the
    671    "lost update" problem).  An If-Match field-value of "*" places the
    672    precondition on the existence of any current representation for the
    673    target resource.
     664   The "If-Match" header field makes the request method conditional on either
     665   the existence of a current representation for the target resource, when
     666   the field-value is "*", or on the selected representation having an
     667   entity-tag that matches one of those provided in the field-value.
    674668</t>
    675669<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/>
     
    677671</artwork></figure>
    678672<t>
    679    The If-Match condition is met if and only if any of the entity-tags listed
    680    in the If-Match field value match the entity-tag of the selected
    681    representation using the weak comparison function (as per <xref
    682    target="entity.tag.comparison"/>), or if "*" is given and any current
     673   Examples:
     674</t>
     675<figure><artwork type="example">
     676  If-Match: "xyzzy"
     677  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
     678  If-Match: *
     679</artwork></figure>
     680<t>
     681   If the request semantics (method and header fields) allow the request to be
     682   satisfied with a cached response, a cache &SHOULD; evaluate the condition
     683   based on its currently stored set of suitable responses for that request
     684   (see &cache-key;).
     685   If the field-value is "*" and any suitable response is currently stored,
     686   or if the field-value is a list of entity-tag values and at least one of
     687   the suitable responses has an <x:ref>ETag</x:ref> header field with a
     688   value matching an entity-tag in that list, then the cache &SHOULD; reuse
     689   the most suitable of those matching responses to satisfy the request.
     690   If the condition is not met, none of the cached responses is suitable for
     691   reuse in response to this request.
     692</t>
     693<t>
     694   If the request semantics cannot be satisfied with a cached response, the
     695   conditional is only evaluated when received by an origin server.
     696   For example, If-Match is most often used with state-changing requests,
     697   such as PUT, to prevent accidental overwrites when multiple user agents
     698   might be acting in parallel on the same resource (i.e., to prevent the
     699   "lost update" problem).
     700</t>
     701<t>
     702   When the If-Match field-value consists of a list of entity-tag values,
     703   the condition is met if any of the entity-tags listed match, using the weak
     704   comparison function (as per <xref target="entity.tag.comparison"/>), the
     705   entity-tag of the selected representation.
     706   When the If-Match field-value is "*", the condition is met if any current
    683707   representation exists for the target resource.
    684708</t>
    685709<t>
    686    If the condition is met, the server &MAY; perform the request method.
     710   If the condition is met, the origin server &MAY; perform the requested
     711   method.
    687712</t>
    688713<t>
     
    694719   state is already reflected in the current state of the target resource
    695720   (i.e., the change requested by the user agent has already succeeded, but
    696    the user agent might not be aware of that due to the prior response message
    697    being lost or because a compatible change was made by some other user
    698    agent). In the latter case, the origin server &MUST-NOT; send a
    699    <x:ref>204 (No Content)</x:ref> status code unless it can verify that the
    700    request is a duplicate of an immediately prior change made by the same user
    701    agent.
    702 </t>
    703 <t>
    704    A proxy using a cached response as the selected representation
    705    &MUST-NOT; perform the requested method if the condition is not met;
    706    instead, the proxy &MUST; forward the request towards the origin server.
    707 </t>
    708 <t>
    709    Examples:
    710 </t>
    711 <figure><artwork type="example">
    712   If-Match: "xyzzy"
    713   If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    714   If-Match: *
    715 </artwork></figure>
     721   the user agent might not be aware of that because the prior response message
     722   was lost or a compatible change was made by some other user agent).
     723   In the latter case, the origin server &MUST-NOT; send a validator header
     724   field in the response unless it can verify that the request is a duplicate
     725   of an immediately prior change made by the same user agent.
     726</t>
    716727</section>
    717728
     
    861872  <x:anchor-alias value="If-Unmodified-Since"/>
    862873<t>
    863    The "If-Unmodified-Since" header field can be used to make a request
    864    method conditional by modification date: if the selected representation
    865    has not been modified since the time specified in this field, then the
    866    condition is met.  If-Unmodified-Since is useful for resource update
    867    requests, when the resource does not provide entity-tag values, as a means
    868    for protecting against accidental overwrites when multiple clients are
    869    acting in parallel on the same resource (i.e., the "lost update" problem).
     874   The "If-Unmodified-Since" header field makes the request method conditional
     875   on the selected representation's last modification date being earlier or
     876   equal to the date provided in the field-value. This field accomplishes the
     877   same purpose as <x:ref>If-Match</x:ref> for cases where the user agent does
     878   not have an entity-tag for the representation.
    870879</t>
    871880<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
     
    879888</artwork></figure>
    880889<t>
    881    If the condition is met, the server &MAY; perform the request method.
     890   A server &MUST; ignore If-Unmodified-Since if the selected representation
     891   has an entity-tag and the request contains an If-Match header field;
     892   the condition in If-Match, when applicable, is considered to be a more
     893   accurate replacement for the condition in If-Unmodified-Since.
     894</t>
     895<t>
     896   A server &MUST; ignore the If-Unmodified-Since header field if the
     897   received field-value is not a valid HTTP-date.
     898</t>
     899<t>
     900   If the request semantics (method and header fields) allow the request to be
     901   satisfied with a cached response, a cache &SHOULD; evaluate the condition
     902   based on its currently stored set of suitable responses for that request
     903   (see &cache-key;).
     904   If the most suitable response has a <x:ref>Last-Modified</x:ref> date that
     905   is earlier or equal to the date given in If-Unmodified-Since, the
     906   cache &SHOULD; reuse that response to satisfy the request.
     907   If the condition is not met, none of the stored responses is suitable for
     908   reuse in response to this request.
     909</t>
     910<t>
     911   If the request semantics cannot be satisfied with a cached response, the
     912   conditional is only evaluated when received by an origin server.
     913   If the selected representation has not been modified since the time
     914   specified in this field, then the condition is met.
     915</t>
     916<t>
     917   If the condition is met, the origin server &MAY; perform the requested
     918   method.
    882919</t>
    883920<t>
     
    889926   state is already reflected in the current state of the target resource
    890927   (i.e., the change requested by the user agent has already succeeded, but
    891    the user agent might not be aware of that due to the prior response message
    892    being lost or because a compatible change was made by some other user
    893    agent). In the latter case, the origin server &MUST-NOT; send a
    894    <x:ref>204 (No Content)</x:ref> status code unless it can verify that the
    895    request is a duplicate of an immediately prior change made by the same user
    896    agent.
    897 </t>
    898 <t>
    899    A proxy using a cached response as the selected representation
    900    &MUST-NOT; perform the requested method if the condition is not met;
    901    instead, the proxy &MUST; forward the request towards the origin server.
    902 </t>
    903 <t>
    904    A server &MUST; ignore the If-Unmodified-Since header field if the
    905    received value is not a valid HTTP-date.
     928   the user agent might not be aware of that because the prior response message
     929   was lost or a compatible change was made by some other user agent).
     930   In the latter case, the origin server &MUST-NOT; send a validator header
     931   field in the response unless it can verify that the request is a duplicate
     932   of an immediately prior change made by the same user agent.
    906933</t>
    907934</section>
Note: See TracChangeset for help on using the changeset viewer.