* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1691


Ignore:
Timestamp:
2012-06-23 04:27:41 (2 years ago)
Author:
julian.reschke@gmx.de
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.