Ignore:
Timestamp:
Jun 23, 2012, 4:27:41 AM (7 years ago)
Author:
julian.reschke@…
Message:

tune conformance requirements (see #271)

Location:
draft-ietf-httpbis/latest
Files:
2 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.
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1689 r1691  
    301301   received.  However, if a resource has distinct representations that differ
    302302   only in their metadata, such as might occur with content negotiation over
    303    media types that happen to share the same data format, then a server
    304    &SHOULD; incorporate additional information in the validator to
     303   media types that happen to share the same data format, then the origin
     304   server &SHOULD; incorporate additional information in the validator to
    305305   distinguish those representations and avoid confusing cache behavior.
    306306</t>
     
    312312   representations of the resource, or due to a desire by the resource owner
    313313   to group representations by some self-determined set of equivalency
    314    rather than unique sequences of data.  A weak entity-tag &SHOULD; change
    315    whenever the origin server considers prior representations to be
    316    unacceptable as a substitute for the current representation. In other
    317    words, a weak entity-tag &SHOULD; change whenever the origin server wants
    318    caches to invalidate old responses.
     314   rather than unique sequences of data.  An origin server &SHOULD; change a
     315   weak entity-tag whenever it considers prior representations to be
     316   unacceptable as a substitute for the current representation. In other words,
     317   a weak entity-tag ought to change whenever the origin server wants caches to
     318   invalidate old responses.
    319319</t>
    320320<t>
     
    715715      last-modified values received or used by these systems will
    716716      support transparent and efficient caching, and so HTTP/1.1 origin
    717       servers should provide Last-Modified values. In those rare cases
     717      servers still ought to provide Last-Modified values. In those rare cases
    718718      where the use of a Last-Modified value as a validator by an
    719719      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
     
    735735  <x:anchor-alias value="If-Match"/>
    736736<t>
    737    The "If-Match" header field &MAY; be used to make a request method
     737   The "If-Match" header field can be used to make a request method
    738738   conditional on the current existence or value of an entity-tag for
    739739   one or more representations of the target resource.  If-Match is
     
    787787  <x:anchor-alias value="If-None-Match"/>
    788788<t>
    789    The "If-None-Match" header field &MAY; be used to make a request method
     789   The "If-None-Match" header field can be used to make a request method
    790790   conditional on not matching any of the current entity-tag values for
    791791   representations of the target resource.  If-None-Match is primarily
     
    798798</t>
    799799<t>
    800    If-None-Match &MAY; also be used with a value of "*" to prevent an unsafe
     800   If-None-Match can also be used with a value of "*" to prevent an unsafe
    801801   request method (e.g., PUT) from inadvertently modifying an existing
    802802   representation of the target resource when the client believes that
     
    857857  <x:anchor-alias value="If-Modified-Since"/>
    858858<t>
    859    The "If-Modified-Since" header field &MAY; be used to make a request
     859   The "If-Modified-Since" header field can be used to make a request
    860860   method conditional by modification date: if the selected representation
    861861   has not been modified since the time specified in this field, then
     
    940940  <x:anchor-alias value="If-Unmodified-Since"/>
    941941<t>
    942    The "If-Unmodified-Since" header field &MAY; be used to make a request
     942   The "If-Unmodified-Since" header field can be used to make a request
    943943   method conditional by modification date: if the selected representation
    944944   has been modified since the time specified in this field, then the
     
    959959</artwork></figure>
    960960<t>
    961    If the request normally (i.e., without the If-Unmodified-Since
     961   If a request normally (i.e., in absence of the If-Unmodified-Since
    962962   header field) would result in anything other than a 2xx or 412 status code,
    963963   the If-Unmodified-Since header field &SHOULD; be ignored.
Note: See TracChangeset for help on using the changeset viewer.