Changeset 2128 for draft-ietf-httpbis/latest

Timestamp:

19/01/13 13:53:26 (10 years ago)

Author:

fielding@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p4-conditional.html (modified) (20 diffs)
• p4-conditional.xml (modified) (18 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 16, 2013"; 
+       content: "Expires July 23, 2013"; 
   } 
   @bottom-right {
@@ -475 +475 @@
       <link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3">
       <link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4">
-      <link rel="Chapter" title="5 Precedence" href="#rfc.section.5">
+      <link rel="Chapter" title="5 Evaluation and Precedence" href="#rfc.section.5">
       <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6">
       <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-19">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -517 +517 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 16, 2013</td>
-               <td class="right">January 12, 2013</td>
+               <td class="left">Expires: July 23, 2013</td>
+               <td class="right">January 19, 2013</td>
             </tr>
          </tbody>
@@ -545 +545 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 16, 2013.</p>
+      <p>This Internet-Draft will expire on July 23, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -581 +581 @@
                   </ul>
                </li>
-               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></li>
+               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></li>
             </ul>
          </li>
@@ -597 +597 @@
             </ul>
          </li>
-         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Precedence</a></li>
+         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Evaluation and Precedence</a></li>
          <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
                <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li>
@@ -666 +666 @@
          in use and imposes restrictions on when weak validators can be used as preconditions.
       </p>
-      <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such
-         that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET.
-      </p>
-      <p id="rfc.section.2.1.p.3">A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored
-         responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same
-         validator unless their payload body would be identical.
+      <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that is changed to a new, previously unused or guaranteed unique,
+         value whenever a change occurs to the representation data such that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET.
+      </p>
+      <p id="rfc.section.2.1.p.3">A strong validator might change for other reasons, such as when a semantically significant part of the representation metadata
+         is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored
+         responses held by remote caches and authoring tools. A strong validator is unique across all representations of a given resource,
+         such that no two representations of that resource share the same validator unless their payload body would be identical.
       </p>
       <p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate
-         an entry using a validator that it obtained in the distant past. A strong validator <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource over time. However, there is no
-         implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for
-         representations of multiple resources at the same time and does not imply that those representations are equivalent).
+         an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations
+         associated with a particular resource over time. However, there is no implication of uniqueness across representations of
+         different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same
+         time and does not imply that those representations are equivalent).
       </p>
       <p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change
@@ -791 +793 @@
   ETag: ""
 </pre><p id="rfc.section.2.3.p.6">An entity-tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity-tag
-         for a representation and the generation of that entity-tag does not satisfy the requirements for a strong validator (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section&nbsp;2.1</a>), then that entity-tag <em class="bcp14">MUST</em> be marked as weak by prefixing its opaque value with "W/" (case-sensitive).
+         for a representation and the generation of that entity-tag does not satisfy the requirements for a strong validator (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section&nbsp;2.1</a>), then the origin server <em class="bcp14">MUST</em> mark the entity-tag as weak by prefixing its opaque value with "W/" (case-sensitive).
       </p>
       <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="entity.tag.generation" href="#entity.tag.generation">Generation</a></h3>
@@ -813 +815 @@
       </p>
       <ul>
-         <li>The strong comparison function: in order to be considered equal, both opaque-tags <em class="bcp14">MUST</em> be identical character-by-character, and both <em class="bcp14">MUST NOT</em> be weak.
-         </li>
-         <li>The weak comparison function: in order to be considered equal, both opaque-tags <em class="bcp14">MUST</em> be identical character-by-character, but either or both of them <em class="bcp14">MAY</em> be tagged as "weak" without affecting the result.
+         <li><dfn>Strong comparison</dfn>: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character.
+         </li>
+         <li><dfn>Weak comparison</dfn>: two entity-tags are equivalent if their opaque-tags match character-by-character, regardless of either or both being tagged
+            as "weak".
          </li>
       </ul>
@@ -895 +898 @@
          </p> 
       </div>
-      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></h2>
+      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="when.to.use.entity.tags.and.last-modified.dates" href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></h2>
       <p id="rfc.section.2.4.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types
          ought to be used, and for what purposes.
       </p>
-      <p id="rfc.section.2.4.p.2">HTTP/1.1 origin servers: </p>
+      <p id="rfc.section.2.4.p.2">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server: 
+      </p>
       <ul>
          <li><em class="bcp14">SHOULD</em> send an entity-tag validator unless it is not feasible to generate one.
@@ -909 +913 @@
          </li>
       </ul>
-      <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value.
-      </p>
-      <p id="rfc.section.2.4.p.4">HTTP/1.1 clients: </p>
+      <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value in successful responses to a retrieval request.
+      </p>
+      <p id="rfc.section.2.4.p.4">A client: </p>
       <ul>
          <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server.
@@ -922 +926 @@
          </li>
       </ul>
-      <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> or <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field) and one or more entity-tags (e.g., in an <a href="#header.if-match" class="smpl">If-Match</a>, <a href="#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> send a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.
-      </p>
-      <p id="rfc.section.2.4.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
-         as cache validators, <em class="bcp14">MUST NOT</em> send a locally cached response to the client unless that cached response is consistent with all of the conditional header
-         fields in the request. 
-      </p>
-      <ul class="empty">
-         <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients ought to transmit as much non-redundant information
-            as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative
-            assumptions about the validators they receive.
-         </li>
-         <li>HTTP/1.0 clients and caches might ignore entity-tags. Generally, last-modified values received or used by these systems will
-            support transparent and efficient caching, and so HTTP/1.1 origin servers still ought to provide Last-Modified values.
-         </li>
-      </ul>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Precondition Header Fields</a></h1>
-      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#precedence" title="Precedence">Section&nbsp;5</a> defines the order of evaluation when more than one precondition is present in a request.
+      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#precedence" title="Evaluation and Precedence">Section&nbsp;5</a> defines when the preconditions are applied and the order of evaluation when more than one precondition is present.
       </p>
       <div id="rfc.iref.i.1"></div>
@@ -953 +942 @@
          of the selected representation for the target resource (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.
       </p>
-      <p id="rfc.section.3.1.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method as if the If-Match header field was not present.
+      <p id="rfc.section.3.1.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method.
       </p>
       <p id="rfc.section.3.1.p.6">Origin servers <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead they <em class="bcp14">MUST</em> respond with the <a href="#status.412" class="smpl">412 (Precondition
@@ -960 +949 @@
       <p id="rfc.section.3.1.p.7">Proxy servers 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, they <em class="bcp14">MUST</em> forward the request towards the origin server.
       </p>
-      <p id="rfc.section.3.1.p.8">If the request would, without the If-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, then the If-Match header field <em class="bcp14">MUST</em> be ignored.
-      </p>
-      <p id="rfc.section.3.1.p.9">Examples:</p>
+      <p id="rfc.section.3.1.p.8">Examples:</p>
       <div id="rfc.figure.u.9"></div><pre class="text">  If-Match: "xyzzy"
   If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
@@ -986 +973 @@
       </p>
       <p id="rfc.section.3.2.p.6">If the condition is not met, 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 <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly <a href="#header.etag" class="smpl">ETag</a>) of the selected representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition
-            Failed)</a> status code.
-      </p>
-      <p id="rfc.section.3.2.p.7">If the condition is met, 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 <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> send a <a href="#status.304" class="smpl">304
-            (Not Modified)</a> response.
-      </p>
-      <p id="rfc.section.3.2.p.8">If the request would, without the If-None-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, then 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;2.4</a> for a discussion of server behavior when both <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> and If-None-Match appear in the same request.)
-      </p>
-      <p id="rfc.section.3.2.p.9">Examples:</p>
+            Failed)</a> status code when the condition is not met.
+      </p>
+      <p id="rfc.section.3.2.p.7">If the condition is met, the server <em class="bcp14">MAY</em> perform the requested method and <em class="bcp14">MUST</em> ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
+      </p>
+      <p id="rfc.section.3.2.p.8">Examples:</p>
       <div id="rfc.figure.u.11"></div><pre class="text">  If-None-Match: "xyzzy"
   If-None-Match: W/"xyzzy"
@@ -1044 +1028 @@
       <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>
       <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
-         representation has been modified since 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 <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since 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.
+         representation has been modified since 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 <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">MAY</em> perform the request.
       </p>
       <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>
 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
       <div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
-</pre><p id="rfc.section.3.4.p.5">If a request normally (i.e., in absence of the If-Unmodified-Since header field) would result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
-      </p>
-      <p id="rfc.section.3.4.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored.
+</pre><p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received value is not a valid HTTP-date.
       </p>
       <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>
@@ -1080 +1062 @@
          and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
       </p>
-      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="precedence" href="#precedence">Precedence</a></h1>
-      <p id="rfc.section.5.p.1">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes
+      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="precedence" href="#precedence">Evaluation and Precedence</a></h1>
+      <p id="rfc.section.5.p.1">For each conditional request, a server <em class="bcp14">MUST</em> evaluate the request preconditions after it has successfully performed its normal request checks (i.e., just before it would
+         perform the action associated with the request method). Preconditions are ignored if the server determines that an error or
+         redirect response applies before they are evaluated.
+      </p>
+      <p id="rfc.section.5.p.2">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes
          important. In practice, the fields defined in this document are consistently implemented in a single, logical order, due to
          the fact that entity tags are presumed to be more accurate than date validators. For example, the only reason to send both <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> and <a href="#header.if-none-match" class="smpl">If-None-Match</a> in the same GET request is to support intermediary caches that might not have implemented <a href="#header.if-none-match" class="smpl">If-None-Match</a>, so it makes sense to ignore the <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> when entity tags are understood and available for the selected representation.
       </p>
-      <p id="rfc.section.5.p.2">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions
+      <p id="rfc.section.5.p.3">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions
          and, within that order, last-modified conditions are only evaluated if the corresponding entity tag condition is not present
          (or not applicable because the selected representation does not have an entity tag).
       </p>
-      <p id="rfc.section.5.p.3">Specifically, the fields defined by this specification are evaluated as follows: </p>
+      <p id="rfc.section.5.p.4">Specifically, the fields defined by this specification are evaluated as follows: </p>
       <ol>
          <li>When <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate it: 
@@ -1123 +1109 @@
          </li>
       </ol>
-      <p id="rfc.section.5.p.4">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding
+      <p id="rfc.section.5.p.5">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding
          the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found
          in practice.
@@ -1305 +1291 @@
          situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section&nbsp;2.3</a>)
       </p>
-      <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Precedence">Section&nbsp;5</a>)
+      <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Evaluation and Precedence">Section&nbsp;5</a>)
       </p>
       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>

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

@@ -209 +209 @@
 </t>
 <t>
-   A "strong validator" is a representation metadata value that &MUST; be
+   A "strong validator" is a representation metadata value that is
    changed to a new, previously unused or guaranteed unique, value whenever
    a change occurs to the representation data such that a change would be
@@ -215 +215 @@
 </t>
 <t>   
-   A strong validator &MAY; be changed for other reasons, such as when a semantically
+   A strong validator might change for other reasons, such as when a semantically
    significant part of the representation metadata is changed (e.g.,
    <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin
    server to only change the value when it is necessary to invalidate the
    stored responses held by remote caches and authoring tools.  A strong
-   validator &MUST; be unique across all representations of a given resource,
+   validator is unique across all representations of a given resource,
    such that no two representations of that resource share the same validator
    unless their payload body would be identical.
@@ -228 +228 @@
    of expiration times.  Thus, a cache might attempt to validate an
    entry using a validator that it obtained in the distant past.
-   A strong validator &MUST; be unique across all versions of all
+   A strong validator is unique across all versions of all
    representations associated with a particular resource over time.
    However, there is no implication of uniqueness across representations
@@ -453 +453 @@
    for a representation and the generation of that entity-tag does not satisfy
    the requirements for a strong validator
-   (<xref target="weak.and.strong.validators"/>), then that
-   entity-tag &MUST; be marked as weak by prefixing its opaque value
+   (<xref target="weak.and.strong.validators"/>), then the origin server
+   &MUST; mark the entity-tag as weak by prefixing its opaque value
    with "W/" (case-sensitive).
 </t>
@@ -489 +489 @@
 <section title="Comparison" anchor="entity.tag.comparison">
   <x:anchor-alias value="validator.comparison"/>
+  <x:anchor-alias value="strong comparison"/>
+  <x:anchor-alias value="weak comparison"/>
 <t>
    There are two entity-tag comparison functions, depending
@@ -494 +496 @@
    or not:
   <list style="symbols">
-     <t>The strong comparison function: in order to be considered equal,
-        both opaque-tags &MUST; be identical character-by-character, and both
-        &MUST-NOT; be weak.</t>
-     <t>The weak comparison function: in order to be considered equal, both
-        opaque-tags &MUST; be identical character-by-character, but
-        either or both of them &MAY; be tagged as "weak" without affecting
-        the result.</t>
+     <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
+        are not weak and their opaque-tags match character-by-character.</t>
+     <t><x:dfn>Weak comparison</x:dfn>: two entity-tags are equivalent if their opaque-tags
+        match character-by-character, regardless of either or both
+        being tagged as "weak".</t>
   </list>
 </t>
@@ -591 +591 @@
 </section>
 
-<section title="Rules for When to Use Entity-tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">
+<section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
 <t>
    We adopt a set of rules and recommendations for origin servers,
@@ -598 +598 @@
 </t>
 <t>
-   HTTP/1.1 origin servers:
+   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
   <list style="symbols">
      <t>&SHOULD; send an entity-tag validator unless it is not feasible to
@@ -612 +612 @@
 </t>
 <t>
-   In other words, the preferred behavior for an HTTP/1.1 origin server
-   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref> value.
-</t>
-<t>
-   HTTP/1.1 clients:
+   In other words, the preferred behavior for an origin server
+   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref>
+   value in successful responses to a retrieval request.
+</t>
+<t>
+   A client:
   <list style="symbols">
      <t>&MUST; use that entity-tag in any cache-conditional request (using
@@ -638 +639 @@
   </list>
 </t>
-<t>
-   An HTTP/1.1 origin server, upon receiving a conditional request that
-   includes both a Last-Modified date (e.g., in an <x:ref>If-Modified-Since</x:ref>
-   or <x:ref>If-Unmodified-Since</x:ref> header field) and one or more
-   entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>,
-   or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT;
-   send a response status code of <x:ref>304 (Not Modified)</x:ref> unless
-   doing so is consistent with all of the conditional header fields in the
-   request.
-</t>
-<t>
-   An HTTP/1.1 caching proxy, upon receiving a conditional request that
-   includes both a Last-Modified date and one or more entity-tags as
-   cache validators, &MUST-NOT; send a locally cached response to the
-   client unless that cached response is consistent with all of the
-   conditional header fields in the request.
-  <list><t>
-      &Note; The general principle behind these rules is that HTTP/1.1
-      servers and clients ought to transmit as much non-redundant
-      information as is available in their responses and requests.
-      HTTP/1.1 systems receiving this information will make the most
-      conservative assumptions about the validators they receive.
-  </t><t>
-      HTTP/1.0 clients and caches might ignore entity-tags. Generally,
-      last-modified values received or used by these systems will
-      support transparent and efficient caching, and so HTTP/1.1 origin
-      servers still ought to provide Last-Modified values.
-  </t></list>
-</t>
 </section>
 </section>
@@ -674 +646 @@
    This section defines the syntax and semantics of HTTP/1.1 header fields
    for applying preconditions on requests.
-   <xref target="precedence"/> defines the order of evaluation when
-   more than one precondition is present in a request.
+   <xref target="precedence"/> defines when the preconditions are applied and
+   the order of evaluation when more than one precondition is present.
 </t>
 
@@ -705 +677 @@
 </t>
 <t>
-   If the condition is met, the server &MAY; perform the request method as if
-   the If-Match header field was not present.
+   If the condition is met, the server &MAY; perform the request method.
 </t>
 <t>
@@ -717 +688 @@
    &MUST-NOT; perform the requested method if the condition is not met;
    instead, they &MUST; forward the request towards the origin server.
-</t>
-<t>
-   If the request would, without the If-Match header field, result in
-   anything other than a <x:ref>2xx (Successful)</x:ref> or <x:ref>412 (Precondition Failed)</x:ref>
-   status code, then the If-Match header field &MUST; be ignored.
 </t>
 <t>
@@ -775 +741 @@
    selected representation that has a matching entity-tag. For all other
    request methods, the server &MUST; respond with a <x:ref>412 (Precondition
-   Failed)</x:ref> status code.
-</t>
-<t>
-   If the condition is met, the server &MAY; perform the requested method
-   as if the If-None-Match header field did not exist, but &MUST; also ignore
-   any <x:ref>If-Modified-Since</x:ref> header field(s) in the request. That
-   is, if no entity-tags match, then the server &MUST-NOT; send a <x:ref>304
-   (Not Modified)</x:ref> response.
-</t>
-<t>
-   If the request would, without the If-None-Match header field, result
-   in anything other than a <x:ref>2xx (Successful)</x:ref> or
-   <x:ref>304 (Not Modified)</x:ref> status code, then the If-None-Match
-   header field &MUST; be ignored. (See <xref
-   target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for
-   a discussion of server behavior when both <x:ref>If-Modified-Since</x:ref>
-   and If-None-Match appear in the same request.)
+   Failed)</x:ref> status code when the condition is not met.
+</t>
+<t>
+   If the condition is met, the server &MAY; perform the requested method and
+   &MUST; ignore any <x:ref>If-Modified-Since</x:ref> header field(s) in the
+   request. That is, if no entity-tags match, then the server &MUST-NOT; send
+   a <x:ref>304 (Not Modified)</x:ref> response.
 </t>
 <t>
@@ -897 +853 @@
    respond with the <x:ref>412 (Precondition Failed)</x:ref> status code.
    If the selected representation has not been modified since the time
-   specified in this field, the server &SHOULD; perform the request
-   method as if the If-Unmodified-Since header field were not present.
+   specified in this field, the server &MAY; perform the request.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
@@ -910 +865 @@
 </artwork></figure>
 <t>
-   If a request normally (i.e., in absence of the If-Unmodified-Since
-   header field) would result in anything other than a <x:ref>2xx (Successful)</x:ref>
-   or <x:ref>412 (Precondition Failed)</x:ref> status code,
-   the If-Unmodified-Since header field &SHOULD; be ignored.
-</t>
-<t>
-   If the specified date is invalid, the header field &MUST; be ignored.
+   A server &MUST; ignore the If-Unmodified-Since header field if the
+   received value is not a valid HTTP-date.
 </t>
 </section>
@@ -982 +932 @@
   <x:anchor-alias value="412 (Precondition Failed)"/>
 <t>
-   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one or more preconditions given in
-   the request header fields evaluated to false when tested on the server.
-   This response code allows the client to place preconditions on the
-   current resource state (its current representations and metadata)
-   and thus prevent the request method from being applied if the target
-   resource is in an unexpected state.
-</t>
-</section>
-</section>
-
-<section title="Precedence" anchor="precedence">
+   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one
+   or more preconditions given in the request header fields evaluated to false
+   when tested on the server. This response code allows the client to place
+   preconditions on the current resource state (its current representations
+   and metadata) and thus prevent the request method from being applied if the
+   target resource is in an unexpected state.
+</t>
+</section>
+</section>
+
+<section title="Evaluation and Precedence" anchor="precedence">
+<t>
+   For each conditional request, a server &MUST; evaluate the request
+   preconditions after it has successfully performed its normal request checks
+   (i.e., just before it would perform the action associated with the request
+   method). Preconditions are ignored if the server determines that an error
+   or redirect response applies before they are evaluated.
+</t>
 <t>
    When more than one conditional request header field is present in a request,
@@ -999 +956 @@
    single, logical order, due to the fact that entity tags are presumed to be
    more accurate than date validators. For example, the only reason to send
-   both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in the same GET request is to
-   support intermediary caches that might not have implemented <x:ref>If-None-Match</x:ref>,
-   so it makes sense to ignore the <x:ref>If-Modified-Since</x:ref> when entity tags are
-   understood and available for the selected representation.
+   both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in
+   the same GET request is to support intermediary caches that might not have
+   implemented <x:ref>If-None-Match</x:ref>, so it makes sense to ignore the
+   <x:ref>If-Modified-Since</x:ref> when entity tags are understood and
+   available for the selected representation.
 </t>
 <t>