Changeset 868 for draft-ietf-httpbis/latest/p4-conditional.html

Timestamp:

22/07/10 09:10:39 (11 years ago)

Author:

fielding@…

Message:

regenerate html

File:

• draft-ietf-httpbis/latest/p4-conditional.html (modified) (10 diffs)

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

@@ -704 +704 @@
       <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>
       <p id="rfc.section.3.2.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This
-         response code allows the client to place preconditions on the current resource metainformation (header field data) and thus
-         prevent the requested method from being applied to a resource other than the one intended.
+         response code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent
+         the requested method from being applied to a resource other than the one intended.
       </p>
       <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>
-      <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different entities,
-         one normally would expect that if the entity (the entity-body or any entity-headers) changes in any way, then the associated
-         validator would change as well. If this is true, then we call this validator a "strong validator."
+      <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different representations,
+         one normally would expect that if the representation (including both representation header fields and representation body)
+         changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong
+         validator."
       </p>
       <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
-         not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is
-         a "weak validator."
+         not when insignificant aspects of the representation change. A validator that does not always change when the representation
+         changes is a "weak validator."
       </p>
       <p id="rfc.section.4.p.3">Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can
-         think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever
-         the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific
-         entity, while a weak validator is part of an identifier for a set of semantically equivalent entities. 
+         think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value
+         changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an
+         identifier for a specific representation, whereas a weak validator is part of an identifier for a set of semantically equivalent
+         representations. 
       </p>
       <ul class="empty">
-         <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
-         </li>
-         <li>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible
-            that the resource might be modified twice during a single second.
+         <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.
+         </li>
+         <li>An entity's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible
+            that the representation might be modified twice during a single second.
          </li>
          <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects;
@@ -736 +738 @@
       </p>
       <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
-         of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator
-         is usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent entity.
+         of a representation. For example, either kind is usable for a normal conditional GET. However, only a strong validator is
+         usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent representation.
       </p>
       <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>).
@@ -795 +797 @@
       </p>
       <ul>
-         <li>The validator is being compared by an origin server to the actual current validator for the entity and,</li>
-         <li>That origin server reliably knows that the associated entity did not change twice during the second covered by the presented
-            validator.
+         <li>The validator is being compared by an origin server to the actual current validator for the representation and,</li>
+         <li>That origin server reliably knows that the associated representation did not change twice during the second covered by the
+            presented validator.
          </li>
       </ul>
@@ -803 +805 @@
       <ul>
          <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has
-            a cache entry for the associated entity, and
+            a cache entry for the associated representation, and
          </li>
          <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
@@ -810 +812 @@
       <p id="rfc.section.4.p.12">or </p>
       <ul>
-         <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and</li>
+         <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation,
+            and
+         </li>
          <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
          <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li>
@@ -892 +896 @@
       <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p>
       <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the entity.
+         receives the message.
       </p>
       <div id="rfc.iref.e.1"></div>
@@ -929 +933 @@
       <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>
   <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
-</pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
-         request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
+</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
+         GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists 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.
       </p>
-      <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current entity exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
+      <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
          such as PUT, from modifying a resource that has changed since the client last retrieved it.
       </p>
@@ -941 +945 @@
       <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
       </p>
-      <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.
-         This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without
-         their knowledge. Examples:
+      <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
+         that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been
+         changed without their knowledge. Examples:
       </p>
       <div id="rfc.figure.u.10"></div><pre class="text">  If-Match: "xyzzy"
@@ -1014 +1018 @@
       <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>
   <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
-</pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
-         request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists 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
-         in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the entities
+</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
+         GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists
+         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
+         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
          that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed).
       </p>
@@ -1075 +1079 @@
          last modification would indicate some time in the future, the server <em class="bcp14">MUST</em> replace that date with the message origination date.
       </p>
-      <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response.
-         This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes
-         near the time that the response is generated.
+      <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date value of
+         its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the
+         representation changes near the time that the response is generated.
       </p>
       <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.