Ignore:
Timestamp:
23/06/12 11:27:41 (8 years ago)
Author:
julian.reschke@…
Message:

tune conformance requirements (see #271)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1689 r1691  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 24, 2012";
     451       content: "Expires December 25, 2012";
    452452  }
    453453  @bottom-right {
    … …  
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
     492      <meta name="dct.issued" scheme="ISO8601" content="2012-06-23">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494494      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    516516            </tr>
    517517            <tr>
    518                <td class="left">Expires: December 24, 2012</td>
     518               <td class="left">Expires: December 25, 2012</td>
    519519               <td class="right">J. Reschke, Editor</td>
    520520            </tr>
    … …  
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">June 22, 2012</td>
     527               <td class="right">June 23, 2012</td>
    528528            </tr>
    529529         </tbody>
    … …  
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on December 24, 2012.</p>
     557      <p>This Internet-Draft will expire on December 25, 2012.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    707707         is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation
    708708         request is received. However, if a resource has distinct representations that differ only in their metadata, such as might
    709          occur with content negotiation over media types that happen to share the same data format, then a server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior.
     709         occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior.
    710710      </p>
    711711      <p id="rfc.section.2.1.p.5">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation
    712712         data. This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to
    713713         ensure uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations
    714          by some self-determined set of equivalency rather than unique sequences of data. A weak entity-tag <em class="bcp14">SHOULD</em> change whenever the origin server considers prior representations to be unacceptable as a substitute for the current representation.
    715          In other words, a weak entity-tag <em class="bcp14">SHOULD</em> change whenever the origin server wants caches to invalidate old responses.
     714         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.
     715         In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.
    716716      </p>
    717717      <p id="rfc.section.2.1.p.6">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might
    … …  
    969969         </li>
    970970         <li>HTTP/1.0 clients and caches might ignore entity-tags. Generally, last-modified values received or used by these systems will
    971             support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare
    972             cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then
    973             HTTP/1.1 origin servers should not provide one.
     971            support transparent and efficient caching, and so HTTP/1.1 origin servers still ought to provide Last-Modified values. In
     972            those rare cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem,
     973            then HTTP/1.1 origin servers should not provide one.
    974974         </li>
    975975      </ul>
    … …  
    979979      <div id="rfc.iref.h.3"></div>
    980980      <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>
    981       <p id="rfc.section.3.1.p.1">The "If-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on the current existence or value of an entity-tag for one or more representations
    982          of the target resource. If-Match is generally useful for resource update requests, such as PUT requests, as a means for protecting
    983          against accidental overwrites when multiple clients are acting in parallel on the same resource (i.e., the "lost update" problem).
    984          An If-Match field-value of "*" places the precondition on the existence of any current representation for the target resource.
     981      <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
     982         for one or more representations of the target resource. If-Match is generally useful for resource update requests, such as
     983         PUT requests, as a means for protecting against accidental overwrites when multiple clients are acting in parallel on the
     984         same resource (i.e., the "lost update" problem). An If-Match field-value of "*" places the precondition on the existence of
     985         any current representation for the target resource.
    985986      </p>
    986987      <div id="rfc.figure.u.9"></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>
    … …  
    10031004      <div id="rfc.iref.h.4"></div>
    10041005      <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>
    1005       <p id="rfc.section.3.2.p.1">The "If-None-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on not matching any of the current entity-tag values for representations of the
    1006          target resource. If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information
    1007          with a minimum amount of transaction overhead. A client that has one or more representations previously obtained from the
    1008          target resource can send If-None-Match with a list of the associated entity-tags in the hope of receiving a 304 response if
    1009          at least one of those representations matches the selected representation.
    1010       </p>
    1011       <p id="rfc.section.3.2.p.2">If-None-Match <em class="bcp14">MAY</em> also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying an existing
    1012          representation of the target resource when the client believes that the resource does not have a current representation. This
    1013          is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation
     1006      <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
     1007         values for representations of the target resource. If-None-Match is primarily used in conditional GET requests to enable efficient
     1008         updates of cached information with a minimum amount of transaction overhead. A client that has one or more representations
     1009         previously obtained from the target resource can send If-None-Match with a list of the associated entity-tags in the hope
     1010         of receiving a 304 response if at least one of those representations matches the selected representation.
     1011      </p>
     1012      <p id="rfc.section.3.2.p.2">If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying
     1013         an existing representation of the target resource when the client believes that the resource does not have a current representation.
     1014         This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation
    10141015         for the target resource.
    10151016      </p>
    … …  
    10361037      <div id="rfc.iref.h.5"></div>
    10371038      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
    1038       <p id="rfc.section.3.3.p.1">The "If-Modified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has not been modified since
    1039          the time specified in this field, then do not perform the request method; instead, respond as detailed below.
     1039      <p id="rfc.section.3.3.p.1">The "If-Modified-Since" header field can be used to make a request method conditional by modification date: if the selected
     1040         representation has not been modified since the time specified in this field, then do not perform the request method; instead,
     1041         respond as detailed below.
    10401042      </p>
    10411043      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a>
    … …  
    10831085      <div id="rfc.iref.h.6"></div>
    10841086      <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>
    1085       <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has been modified since
    1086          the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the 412 (Precondition Failed) status code. If the selected representation has not been modified since
     1087      <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
     1088         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 412 (Precondition Failed) status code. If the selected representation has not been modified since
    10871089         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.
    10881090      </p>
    … …  
    10901092</pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
    10911093      <div id="rfc.figure.u.16"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1092 </pre><p id="rfc.section.3.4.p.5">If the request normally (i.e., without the If-Unmodified-Since header field) would result in anything other than a 2xx or
    1093          412 status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
     1094</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 2xx
     1095         or 412 status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
    10941096      </p>
    10951097      <p id="rfc.section.3.4.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored.
Note: See TracChangeset for help on using the changeset viewer.