Changeset 2671


Ignore:
Timestamp:
May 14, 2014, 5:58:12 AM (6 years ago)
Author:
julian.reschke@…
Message:

grammar (#553)

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

Legend:

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

    r2667 r2671  
    463463  }
    464464  @bottom-center {
    465        content: "Expires November 13, 2014";
     465       content: "Expires November 15, 2014";
    466466  }
    467467  @bottom-right {
     
    506506      <meta name="dct.creator" content="Reschke, J. F.">
    507507      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    508       <meta name="dct.issued" scheme="ISO8601" content="2014-05-12">
     508      <meta name="dct.issued" scheme="ISO8601" content="2014-05-14">
    509509      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    510510      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless 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.">
     
    532532            </tr>
    533533            <tr>
    534                <td class="left">Expires: November 13, 2014</td>
    535                <td class="right">May 12, 2014</td>
     534               <td class="left">Expires: November 15, 2014</td>
     535               <td class="right">May 14, 2014</td>
    536536            </tr>
    537537         </tbody>
     
    561561            in progress”.
    562562         </p>
    563          <p>This Internet-Draft will expire on November 13, 2014.</p>
     563         <p>This Internet-Draft will expire on November 15, 2014.</p>
    564564      </div>
    565565      <div id="rfc.copyrightnotice">
     
    597597                     <li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.generation">Generation</a></li>
    598598                     <li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.comparison">Comparison</a></li>
    599                      <li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-tags Varying on Content-Negotiated Resources</a></li>
     599                     <li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></li>
    600600                  </ul>
    601601               </li>
    602                <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>
     602               <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>
    603603            </ul>
    604604         </li>
     
    674674         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1>
    675675         <p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions:
    676             modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as WebDAV <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.
     676            modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed
     677            Authoring and Versioning (WebDAV, <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>), that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.
    677678         </p>
    678679         <div id="weak.and.strong.validators">
     
    707708            </p>
    708709            <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data.
    709                This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to ensure
    710                uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations
    711                by some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation.
     710               This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure
     711               uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by
     712               some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation.
    712713               In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.
    713714            </p>
     
    791792               <p id="rfc.section.2.2.2.p.4">This method relies on the fact that if two different responses were sent by the origin server during the same second, but
    792793                  both had the same Last-Modified time, then at least one of those responses would have a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified
    793                   values are generated from different clocks, or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
     794                  values are generated from different clocks or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
    794795               </p>
    795796            </div>
     
    812813             ; <a href="#imported.abnf" class="smpl">VCHAR</a> except double quotes, plus obs-text
    813814</pre><div class="note" id="rfc.section.2.3.p.3">
    814                <p><b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>), thus some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity
     815               <p><b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>); thus, some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity
    815816                  tags.
    816817               </p>
     
    840841                  or a modification timestamp that has sub-second resolution.
    841842               </p>
    842                <p id="rfc.section.2.3.1.p.3">An origin server <em class="bcp14">SHOULD</em> send ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since
    843                   the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability
     843               <p id="rfc.section.2.3.1.p.3">An origin server <em class="bcp14">SHOULD</em> send an ETag for any selected representation for which detection of changes can be reasonably and consistently determined,
     844                  since the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability
    844845                  and reliability.
    845846               </p>
     
    847848            <div id="entity.tag.comparison">
    848849               <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a href="#entity.tag.comparison">Comparison</a></h3>
    849                <p id="rfc.section.2.3.2.p.1">There are two entity-tag comparison functions, depending on whether the comparison context allows the use of weak validators
    850                   or not:
    851                </p>
     850               <p id="rfc.section.2.3.2.p.1">There are two entity-tag comparison functions, depending on whether or not the comparison context allows the use of weak validators: </p>
    852851               <ul>
    853852                  <li><dfn>Strong comparison</dfn>: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character.
     
    857856                  </li>
    858857               </ul>
    859                <p id="rfc.section.2.3.2.p.2">The example below shows the results for a set of entity-tag pairs, and both the weak and strong comparison function results:</p>
     858               <p id="rfc.section.2.3.2.p.2">The example below shows the results for a set of entity-tag pairs and both the weak and strong comparison function results:</p>
    860859               <div id="rfc.table.u.1">
    861860                  <table class="tt full left" cellpadding="3" cellspacing="0">
     
    898897            </div>
    899898            <div id="example.entity.tag.vs.conneg">
    900                <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-tags Varying on Content-Negotiated Resources</a></h3>
     899               <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></h3>
    901900               <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), and where the representations sent in response to a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 5.3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>):
    902901               </p>
     
    939938         </div>
    940939         <div id="when.to.use.entity.tags.and.last-modified.dates">
    941             <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></h2>
     940            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-Tags and Last-Modified Dates</a></h2>
    942941            <p id="rfc.section.2.4.p.1">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server:
    943942            </p>
     
    993992               of the selected representation.
    994993            </p>
    995             <p id="rfc.section.3.1.p.8">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if a received If-Match condition evaluates to false; 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
     994            <p id="rfc.section.3.1.p.8">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if a received If-Match condition evaluates to false; 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
    996995               in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
    997996               agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other
     
    10301029               selected representation.
    10311030            </p>
    1032             <p id="rfc.section.3.2.p.9">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.304" class="smpl">304 (Not Modified)</a> status code if the request method is GET or HEAD; or, b) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code for all other request methods.
     1031            <p id="rfc.section.3.2.p.9">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.304" class="smpl">304 (Not Modified)</a> status code if the request method is GET or HEAD or b) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code for all other request methods.
    10331032            </p>
    10341033            <p id="rfc.section.3.2.p.10">Requirements on cache handling of a received If-None-Match header field are defined in <a href="p6-cache.html#validation.received" title="Handling a Received Validation Request">Section 4.3.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
     
    10451044</pre><p id="rfc.section.3.3.p.3">An example of the field is:</p>
    10461045            <div id="rfc.figure.u.13"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1047 </pre><p id="rfc.section.3.3.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Modified-Since if the request contains an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field; the condition in <a href="#header.if-none-match" class="smpl">If-None-Match</a> is considered to be a more accurate replacement for the condition in If-Modified-Since and the two are only combined for the
    1048                sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>.
     1046</pre><p id="rfc.section.3.3.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Modified-Since if the request contains an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field; the condition in <a href="#header.if-none-match" class="smpl">If-None-Match</a> is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for
     1047               the sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>.
    10491048            </p>
    10501049            <p id="rfc.section.3.3.p.6">A recipient <em class="bcp14">MUST</em> ignore the If-Modified-Since header field if the received field-value is not a valid HTTP-date, or if the request method is
     
    10541053            </p>
    10551054            <p id="rfc.section.3.3.p.8">If-Modified-Since is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that
    1056                does not have an entity-tag; and, 2) to limit the scope of a web traversal to resources that have recently changed.
     1055               does not have an entity-tag and 2) to limit the scope of a web traversal to resources that have recently changed.
    10571056            </p>
    10581057            <p id="rfc.section.3.3.p.9">When used for cache updates, a cache will typically use the value of the cached message's <a href="#header.last-modified" class="smpl">Last-Modified</a> field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly
     
    10811080</pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
    10821081            <div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1083 </pre><p id="rfc.section.3.4.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the request contains an <a href="#header.if-match" class="smpl">If-Match</a> header field; the condition in <a href="#header.if-match" class="smpl">If-Match</a> is considered to be a more accurate replacement for the condition in If-Unmodified-Since and the two are only combined for
     1082</pre><p id="rfc.section.3.4.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the request contains an <a href="#header.if-match" class="smpl">If-Match</a> header field; the condition in <a href="#header.if-match" class="smpl">If-Match</a> is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for
    10841083               the sake of interoperating with older intermediaries that might not implement <a href="#header.if-match" class="smpl">If-Match</a>.
    10851084            </p>
     
    10931092            </p>
    10941093            <p id="rfc.section.3.4.p.9">An origin server that receives an If-Unmodified-Since header field <em class="bcp14">MUST</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). The origin server <em class="bcp14">MUST NOT</em> perform the requested method if the selected representation's last modification date is more recent than the date provided
    1095                in the field-value; 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
     1094               in the field-value; 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
    10961095               in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
    10971096               agent might not be aware of that because the prior response message was lost or a compatible change was made by some other
     
    11051104         <div id="header.if-range">
    11061105            <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a href="#header.if-range">If-Range</a></h2>
    1107             <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header fields but instructs the recipient to ignore the <a href="p5-range.html#header.range" class="smpl">Range</a> header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 response.
     1106            <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header fields but that instructs the recipient to ignore the <a href="p5-range.html#header.range" class="smpl">Range</a> header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 response.
    11081107               If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>.
    11091108            </p>
     
    11151114            <div id="rfc.iref.21"></div>
    11161115            <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#status.304">304 Not Modified</a></h2>
    1117             <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET or HEAD request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
     1116            <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET or HEAD request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server
    11181117               to transfer a representation of the target resource because the request indicates that the client, which made the request
    11191118               conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored
     
    11361135            <p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the
    11371136               server. This response code allows the client to place preconditions on the current resource state (its current representations
    1138                and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
     1137               and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.
    11391138            </p>
    11401139         </div>
     
    11461145            other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a>. In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
    11471146         </p>
    1148          <p id="rfc.section.5.p.2">A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource <em class="bcp14">MUST NOT</em> evaluate the conditional request header fields defined by this specification, and <em class="bcp14">MUST</em> forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can
     1147         <p id="rfc.section.5.p.2">A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource <em class="bcp14">MUST NOT</em> evaluate the conditional request header fields defined by this specification, and it <em class="bcp14">MUST</em> forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can
    11491148            provide a current representation. Likewise, a server <em class="bcp14">MUST</em> ignore the conditional request header fields defined by this specification when received with a request method that does not
    11501149            involve the selection or modification of a <a href="p2-semantics.html#representations" class="smpl">selected representation</a>, such as CONNECT, OPTIONS, or TRACE.
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2667 r2671  
    200200   (<xref target="header.last-modified"/>) and opaque entity tags
    201201   (<xref target="header.etag"/>).  Additional metadata that reflects resource state
    202    has been defined by various extensions of HTTP, such as WebDAV
    203    <xref target="RFC4918"/>, that are beyond the scope of this specification.
     202   has been defined by various extensions of HTTP, such as Web Distributed
     203   Authoring and Versioning (WebDAV, <xref target="RFC4918"/>), that are beyond the scope of this specification.
    204204   A resource metadata value is referred to as a "<x:dfn>validator</x:dfn>"
    205205   when it is used within a precondition.
     
    260260   might not change for every change to the representation data.  This
    261261   weakness might be due to limitations in how the value is calculated, such
    262    as clock resolution or an inability to ensure uniqueness for all possible
    263    representations of the resource, or due to a desire by the resource owner
     262   as clock resolution, an inability to ensure uniqueness for all possible
     263   representations of the resource, or a desire of the resource owner
    264264   to group representations by some self-determined set of equivalency
    265265   rather than unique sequences of data.  An origin server &SHOULD; change a
     
    406406   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
    407407   arbitrary 60-second limit guards against the possibility that the Date and
    408    Last-Modified values are generated from different clocks, or at somewhat
     408   Last-Modified values are generated from different clocks or at somewhat
    409409   different times during the preparation of the response. An
    410410   implementation &MAY; use a value larger than 60 seconds, if it is
     
    444444  <t>
    445445    &Note; Previously, opaque-tag was defined to be a quoted-string
    446     (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>), thus some recipients
     446    (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>); thus, some recipients
    447447    might perform backslash unescaping. Servers therefore ought to avoid
    448448    backslash characters in entity tags.
     
    492492</t>
    493493<t>
    494    An origin server &SHOULD; send ETag for any selected representation
     494   An origin server &SHOULD; send an ETag for any selected representation
    495495   for which detection of changes can be reasonably and consistently
    496496   determined, since the entity-tag's use in conditional requests and
     
    506506  <x:anchor-alias value="weak comparison"/>
    507507<t>
    508    There are two entity-tag comparison functions, depending
    509    on whether the comparison context allows the use of weak validators
    510    or not:
     508   There are two entity-tag comparison functions, depending on whether or not
     509   the comparison context allows the use of weak validators:
    511510  <list style="symbols">
    512511     <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
     
    518517</t>
    519518<t>
    520    The example below shows the results for a set of entity-tag pairs,
    521    and both the weak and strong comparison function results:
     519   The example below shows the results for a set of entity-tag pairs and both
     520   the weak and strong comparison function results:
    522521</t>
    523522<texttable align="left">
     
    549548</section>
    550549
    551 <section title="Example: Entity-tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
     550<section title="Example: Entity-Tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
    552551<t>
    553552   Consider a resource that is subject to content negotiation
     
    606605</section>
    607606
    608 <section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
     607<section title="When to Use Entity-Tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
    609608<t>
    610609   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
     
    707706<t>
    708707   An origin server &MUST-NOT; perform the requested method if a received
    709    If-Match condition evaluates to false; instead the origin server &MUST;
    710    respond with either:
    711    a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or,
     708   If-Match condition evaluates to false; instead, the origin server &MUST;
     709   respond with either
     710   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
    712711   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
    713712   server has verified that a state change is being requested and the final
     
    787786   evaluates to false; instead, the origin server &MUST; respond with either
    788787   a) the <x:ref>304 (Not Modified)</x:ref> status code if the request method
    789    is GET or HEAD; or,
    790    b) the <x:ref>412 (Precondition Failed)</x:ref> status code for all other
    791    request methods.
     788   is GET or HEAD or b) the <x:ref>412 (Precondition Failed)</x:ref> status
     789   code for all other request methods.
    792790</t>
    793791<t>
     
    819817   <x:ref>If-None-Match</x:ref> header field; the condition in
    820818   <x:ref>If-None-Match</x:ref> is considered to be a more accurate
    821    replacement for the condition in If-Modified-Since and the two are only
     819   replacement for the condition in If-Modified-Since, and the two are only
    822820   combined for the sake of interoperating with older intermediaries that
    823821   might not implement <x:ref>If-None-Match</x:ref>.
     
    835833   If-Modified-Since is typically used for two distinct purposes:
    836834   1) to allow efficient updates of a cached representation that does not
    837    have an entity-tag; and,
    838    2) to limit the scope of a web traversal to resources that have recently
    839    changed.
     835   have an entity-tag and 2) to limit the scope of a web traversal to resources
     836   that have recently changed.
    840837</t>
    841838<t>
     
    901898   <x:ref>If-Match</x:ref> header field; the condition in
    902899   <x:ref>If-Match</x:ref> is considered to be a more accurate replacement for
    903    the condition in If-Unmodified-Since and the two are only combined for the
     900   the condition in If-Unmodified-Since, and the two are only combined for the
    904901   sake of interoperating with older intermediaries that might not implement
    905902   <x:ref>If-Match</x:ref>.
     
    928925   The origin server &MUST-NOT; perform the requested method if the selected
    929926   representation's last modification date is more recent than the date
    930    provided in the field-value; instead the
    931    origin server &MUST; respond with either:
    932    a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or,
     927   provided in the field-value; instead the origin server &MUST; respond with either
     928   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
    933929   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
    934930   server has verified that a state change is being requested and the final
     
    951947   The "If-Range" header field provides a special conditional request
    952948   mechanism that is similar to the <x:ref>If-Match</x:ref> and
    953    <x:ref>If-Unmodified-Since</x:ref> header fields but instructs the
     949   <x:ref>If-Unmodified-Since</x:ref> header fields but that instructs the
    954950   recipient to ignore the <x:ref>Range</x:ref> header field if the validator
    955951   doesn't match, resulting in transfer of the new selected representation
     
    968964   conditional GET or HEAD request has been
    969965   received and would have resulted in a <x:ref>200 (OK)</x:ref> response
    970    if it were not for the fact that the condition has evaluated to false.
     966   if it were not for the fact that the condition evaluated to false.
    971967   In other words, there is no need for the server to transfer a
    972968   representation of the target resource because the request indicates that
     
    10161012   when tested on the server. This response code allows the client to place
    10171013   preconditions on the current resource state (its current representations
    1018    and metadata) and thus prevent the request method from being applied if the
     1014   and metadata) and, thus, prevent the request method from being applied if the
    10191015   target resource is in an unexpected state.
    10201016</t>
     
    10371033   A server that is not the origin server for the target resource and cannot
    10381034   act as a cache for requests on the target resource &MUST-NOT; evaluate the
    1039    conditional request header fields defined by this specification, and
     1035   conditional request header fields defined by this specification, and it
    10401036   &MUST; forward them if the request is forwarded, since the generating
    10411037   client intends that they be evaluated by a server that can provide a
Note: See TracChangeset for help on using the changeset viewer.