Changeset 1691 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 23/06/12 11:27:41 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1689 r1691 449 449 } 450 450 @bottom-center { 451 content: "Expires December 2 4, 2012";451 content: "Expires December 25, 2012"; 452 452 } 453 453 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2012-06-2 2">492 <meta name="dct.issued" scheme="ISO8601" content="2012-06-23"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <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 "HTTP/1.1" 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."> … … 516 516 </tr> 517 517 <tr> 518 <td class="left">Expires: December 2 4, 2012</td>518 <td class="left">Expires: December 25, 2012</td> 519 519 <td class="right">J. Reschke, Editor</td> 520 520 </tr> … … 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">June 2 2, 2012</td>527 <td class="right">June 23, 2012</td> 528 528 </tr> 529 529 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on December 2 4, 2012.</p>557 <p>This Internet-Draft will expire on December 25, 2012.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 707 707 is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation 708 708 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 aserver <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. 710 710 </p> 711 711 <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 712 712 data. This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to 713 713 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 serverconsiders 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. 716 716 </p> 717 717 <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 … … 969 969 </li> 970 970 <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 s hould provide Last-Modified values. In those rare972 cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then973 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. 974 974 </li> 975 975 </ul> … … 979 979 <div id="rfc.iref.h.3"></div> 980 980 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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. 985 986 </p> 986 987 <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> … … 1003 1004 <div id="rfc.iref.h.4"></div> 1004 1005 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <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 the1006 target resource. If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information1007 with a minimum amount of transaction overhead. A client that has one or more representations previously obtained from the1008 target resource can send If-None-Match with a list of the associated entity-tags in the hope of receiving a 304 response if1009 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 existing1012 representation of the target resource when the client believes that the resource does not have a current representation. This1013 is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation1006 <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 1014 1015 for the target resource. 1015 1016 </p> … … 1036 1037 <div id="rfc.iref.h.5"></div> 1037 1038 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <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. 1040 1042 </p> 1041 1043 <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> … … 1083 1085 <div id="rfc.iref.h.6"></div> 1084 1086 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <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 since1086 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 since1087 <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 1087 1089 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. 1088 1090 </p> … … 1090 1092 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p> 1091 1093 <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 or1093 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. 1094 1096 </p> 1095 1097 <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.