draft-ietf-httpbis-p4-conditional-12.txt | draft-ietf-httpbis-p4-conditional-13.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Day Software | Internet-Draft Adobe | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Intended status: Standards Track Alcatel-Lucent | Intended status: Standards Track Alcatel-Lucent | |||
Expires: April 28, 2011 J. Mogul | Expires: September 15, 2011 J. Mogul | |||
HP | HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe Systems | Adobe | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
October 25, 2010 | March 14, 2011 | |||
HTTP/1.1, part 4: Conditional Requests | HTTP/1.1, part 4: Conditional Requests | |||
draft-ietf-httpbis-p4-conditional-12 | draft-ietf-httpbis-p4-conditional-13 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 4 of the | information initiative since 1990. This document is Part 4 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines | |||
request header fields for indicating conditional requests and the | request header fields for indicating conditional requests and the | |||
rules for constructing responses to those requests. | rules for constructing responses to those requests. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org). The current issues list is | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix C.13. | The changes in this draft are summarized in Appendix C.14. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on April 28, 2011. | This Internet-Draft will expire on September 15, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 3, line 29 | skipping to change at page 3, line 29 | |||
4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 9 | 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 9 | |||
5. Rules for When to Use Entity-tags and Last-Modified Dates . . 11 | 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 11 | |||
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 13 | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 | 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 | |||
6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 17 | 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 17 | |||
6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 | 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 | |||
6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 19 | 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 19 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
7.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 | 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 | |||
7.2. Header Field Registration . . . . . . . . . . . . . . . . 20 | 7.2. Header Field Registration . . . . . . . . . . . . . . . . 20 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 | |||
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 | |||
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 | |||
Appendix C. Change Log (to be removed by RFC Editor before | Appendix C. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 22 | publication) . . . . . . . . . . . . . . . . . . . . 22 | |||
skipping to change at page 4, line 4 | skipping to change at page 4, line 4 | |||
C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 | |||
C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 | |||
C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24 | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24 | |||
C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 | |||
C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 | |||
C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 | |||
C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 | C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 | |||
C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 | C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 | |||
C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 | C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 | |||
C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 | C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 | |||
C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
1. Introduction | 1. Introduction | |||
This document defines HTTP/1.1 response metadata for indicating | This document defines HTTP/1.1 response metadata for indicating | |||
potential changes to payload content, including modification time | potential changes to payload content, including modification time | |||
stamps and opaque entity-tags, and the HTTP conditional request | stamps and opaque entity-tags, and the HTTP conditional request | |||
mechanisms that allow preconditions to be placed on a request method. | mechanisms that allow preconditions to be placed on a request method. | |||
Conditional GET requests allow for efficient cache updates. Other | Conditional GET requests allow for efficient cache updates. Other | |||
conditional request methods are used to protect against overwriting | conditional request methods are used to protect against overwriting | |||
or misunderstanding the state of a resource that has been changed | or misunderstanding the state of a resource that has been changed | |||
unbeknownst to the requesting client. | unbeknownst to the requesting client. | |||
This document is currently disorganized in order to minimize the | This document is currently disorganized in order to minimize the | |||
changes between drafts and enable reviewers to see the smaller errata | changes between drafts and enable reviewers to see the smaller errata | |||
changes. A future draft will reorganize the sections to better | changes. A future draft will reorganize the sections to better | |||
reflect the content. In particular, the sections on resource | reflect the content. In particular, the sections on resource | |||
metadata will be discussed first and then followed by each | metadata will be discussed first and then followed by each | |||
conditional request-header field, concluding with a definition of | conditional request header field, concluding with a definition of | |||
precedence and the expectation of ordering strong validator checks | precedence and the expectation of ordering strong validator checks | |||
before weak validator checks. It is likely that more content from | before weak validator checks. It is likely that more content from | |||
[Part6] will migrate to this part, where appropriate. The current | [Part6] will migrate to this part, where appropriate. The current | |||
mess reflects how widely dispersed these topics and associated | mess reflects how widely dispersed these topics and associated | |||
requirements had become in [RFC2616]. | requirements had become in [RFC2616]. | |||
1.1. Requirements | 1.1. Requirements | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
skipping to change at page 8, line 50 | skipping to change at page 8, line 50 | |||
response MAY be forwarded to the outbound client. Otherwise, | response MAY be forwarded to the outbound client. Otherwise, | |||
disregard the response and repeat the request without the | disregard the response and repeat the request without the | |||
conditional. | conditional. | |||
If a cache uses a received 304 response to update a cache entry, the | If a cache uses a received 304 response to update a cache entry, the | |||
cache MUST update the entry to reflect any new field values given in | cache MUST update the entry to reflect any new field values given in | |||
the response. | the response. | |||
3.2. 412 Precondition Failed | 3.2. 412 Precondition Failed | |||
The precondition given in one or more of the request-header fields | The precondition given in one or more of the header fields evaluated | |||
evaluated to false when it was tested on the server. This response | to false when it was tested on the server. This response code allows | |||
code allows the client to place preconditions on the current resource | the client to place preconditions on the current resource metadata | |||
metadata (header field data) and thus prevent the requested method | (header field data) and thus prevent the requested method from being | |||
from being applied to a resource other than the one intended. | applied to a resource other than the one intended. | |||
4. Weak and Strong Validators | 4. Weak and Strong Validators | |||
Since both origin servers and caches will compare two validators to | Since both origin servers and caches will compare two validators to | |||
decide if they represent the same or different representations, one | decide if they represent the same or different representations, one | |||
normally would expect that if the representation (including both | normally would expect that if the representation (including both | |||
representation header fields and representation body) changes in any | representation header fields and representation body) changes in any | |||
way, then the associated validator would change as well. If this is | way, then the associated validator would change as well. If this is | |||
true, then we call this validator a "strong validator". | true, then we call this validator a "strong validator". | |||
skipping to change at page 12, line 23 | skipping to change at page 12, line 23 | |||
if it is unfeasible to send a strong entity-tag. | if it is unfeasible to send a strong entity-tag. | |||
o SHOULD send a Last-Modified value if it is feasible to send one, | o SHOULD send a Last-Modified value if it is feasible to send one, | |||
unless the risk of a breakdown in semantic transparency that could | unless the risk of a breakdown in semantic transparency that could | |||
result from using this date in an If-Modified-Since header field | result from using this date in an If-Modified-Since header field | |||
would lead to serious problems. | would lead to serious problems. | |||
In other words, the preferred behavior for an HTTP/1.1 origin server | In other words, the preferred behavior for an HTTP/1.1 origin server | |||
is to send both a strong entity-tag and a Last-Modified value. | is to send both a strong entity-tag and a Last-Modified value. | |||
In order to be legal, a strong entity-tag MUST change whenever the | In order to be legitimate, a strong entity-tag MUST change whenever | |||
associated representation changes in any way. A weak entity-tag | the associated representation changes in any way. A weak entity-tag | |||
SHOULD change whenever the associated representation changes in a | SHOULD change whenever the associated representation changes in a | |||
semantically significant way. | semantically significant way. | |||
Note: In order to provide semantically transparent caching, an | Note: In order to provide semantically transparent caching, an | |||
origin server must avoid reusing a specific strong entity-tag | origin server must avoid reusing a specific strong entity-tag | |||
value for two different representations, or reusing a specific | value for two different representations, or reusing a specific | |||
weak entity-tag value for two semantically different | weak entity-tag value for two semantically different | |||
representations. Cache entries might persist for arbitrarily long | representations. Cache entries might persist for arbitrarily long | |||
periods, regardless of expiration times, so it might be | periods, regardless of expiration times, so it might be | |||
inappropriate to expect that a cache will never again attempt to | inappropriate to expect that a cache will never again attempt to | |||
skipping to change at page 13, line 30 | skipping to change at page 13, line 30 | |||
cache validators, MUST NOT return a locally cached response to the | cache validators, MUST NOT return a locally cached response to the | |||
client unless that cached response is consistent with all of the | client unless that cached response is consistent with all of the | |||
conditional header fields in the request. | conditional header fields in the request. | |||
Note: The general principle behind these rules is that HTTP/1.1 | Note: The general principle behind these rules is that HTTP/1.1 | |||
servers and clients ought to transmit as much non-redundant | servers and clients ought to transmit as much non-redundant | |||
information as is available in their responses and requests. | information as is available in their responses and requests. | |||
HTTP/1.1 systems receiving this information will make the most | HTTP/1.1 systems receiving this information will make the most | |||
conservative assumptions about the validators they receive. | conservative assumptions about the validators they receive. | |||
HTTP/1.0 clients and caches will ignore entity-tags. Generally, | HTTP/1.0 clients and caches might ignore entity-tags. Generally, | |||
last-modified values received or used by these systems will | last-modified values received or used by these systems will | |||
support transparent and efficient caching, and so HTTP/1.1 origin | support transparent and efficient caching, and so HTTP/1.1 origin | |||
servers should provide Last-Modified values. In those rare cases | servers should provide Last-Modified values. In those rare cases | |||
where the use of a Last-Modified value as a validator by an | where the use of a Last-Modified value as a validator by an | |||
HTTP/1.0 system could result in a serious problem, then HTTP/1.1 | HTTP/1.0 system could result in a serious problem, then HTTP/1.1 | |||
origin servers should not provide one. | origin servers should not provide one. | |||
6. Header Field Definitions | 6. Header Field Definitions | |||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
fields related to conditional requests. | fields related to conditional requests. | |||
6.1. ETag | 6.1. ETag | |||
The "ETag" response-header field provides the current value of the | The "ETag" header field provides the current value of the entity-tag | |||
entity-tag (see Section 2) for one representation of the target | (see Section 2) for one representation of the target resource. An | |||
resource. An entity-tag is intended for use as a resource-local | entity-tag is intended for use as a resource-local identifier for | |||
identifier for differentiating between representations of the same | differentiating between representations of the same resource that | |||
resource that vary over time or via content negotiation (see | vary over time or via content negotiation (see Section 4). | |||
Section 4). | ||||
ETag = "ETag" ":" OWS ETag-v | ETag = "ETag" ":" OWS ETag-v | |||
ETag-v = entity-tag | ETag-v = entity-tag | |||
Examples: | Examples: | |||
ETag: "xyzzy" | ETag: "xyzzy" | |||
ETag: W/"xyzzy" | ETag: W/"xyzzy" | |||
ETag: "" | ETag: "" | |||
skipping to change at page 14, line 29 | skipping to change at page 14, line 28 | |||
The principle behind entity-tags is that only the service author | The principle behind entity-tags is that only the service author | |||
knows the semantics of a resource well enough to select an | knows the semantics of a resource well enough to select an | |||
appropriate cache validation mechanism, and the specification of any | appropriate cache validation mechanism, and the specification of any | |||
validator comparison function more complex than byte-equality would | validator comparison function more complex than byte-equality would | |||
open up a can of worms. Thus, comparisons of any other header fields | open up a can of worms. Thus, comparisons of any other header fields | |||
(except Last-Modified, for compatibility with HTTP/1.0) are never | (except Last-Modified, for compatibility with HTTP/1.0) are never | |||
used for purposes of validating a cache entry. | used for purposes of validating a cache entry. | |||
6.2. If-Match | 6.2. If-Match | |||
The "If-Match" request-header field is used to make a request method | The "If-Match" header field is used to make a request method | |||
conditional. A client that has one or more representations | conditional. A client that has one or more representations | |||
previously obtained from the resource can verify that one of those | previously obtained from the resource can verify that one of those | |||
representations is current by including a list of their associated | representations is current by including a list of their associated | |||
entity-tags in the If-Match header field. | entity-tags in the If-Match header field. | |||
This allows efficient updates of cached information with a minimum | This allows efficient updates of cached information with a minimum | |||
amount of transaction overhead. It is also used when updating | amount of transaction overhead. It is also used when updating | |||
resources, to prevent inadvertent modification of the wrong version | resources, to prevent inadvertent modification of the wrong version | |||
of a resource. As a special case, the value "*" matches any current | of a resource. As a special case, the value "*" matches any current | |||
representation of the resource. | representation of the resource. | |||
skipping to change at page 15, line 7 | skipping to change at page 15, line 5 | |||
that would have been returned in the response to a similar GET | that would have been returned in the response to a similar GET | |||
request (without the If-Match header field) on that resource, or if | request (without the If-Match header field) on that resource, or if | |||
"*" is given and any current representation exists for that resource, | "*" is given and any current representation exists for that resource, | |||
then the server MAY perform the requested method as if the If-Match | then the server MAY perform the requested method as if the If-Match | |||
header field did not exist. | header field did not exist. | |||
If none of the entity-tags match, or if "*" is given and no current | If none of the entity-tags match, or if "*" is given and no current | |||
representation exists, the server MUST NOT perform the requested | representation exists, the server MUST NOT perform the requested | |||
method, and MUST return a 412 (Precondition Failed) response. This | method, and MUST return a 412 (Precondition Failed) response. This | |||
behavior is most useful when the client wants to prevent an updating | behavior is most useful when the client wants to prevent an updating | |||
method, such as PUT, from modifying a resource that has changed since | request method, such as PUT, from modifying a resource that has | |||
the client last retrieved it. | changed since the client last retrieved it. | |||
If the request would, without the If-Match header field, result in | If the request would, without the If-Match header field, result in | |||
anything other than a 2xx or 412 status code, then the If-Match | anything other than a 2xx or 412 status code, then the If-Match | |||
header field MUST be ignored. | header field MUST be ignored. | |||
The meaning of "If-Match: *" is that the method SHOULD be performed | The meaning of "If-Match: *" is that the request method SHOULD be | |||
if the representation selected by the origin server (or by a cache, | performed if the representation selected by the origin server (or by | |||
possibly using the Vary mechanism, see Section 3.5 of [Part6]) | a cache, possibly using the Vary mechanism, see Section 3.5 of | |||
exists, and MUST NOT be performed if the representation does not | [Part6]) exists, and MUST NOT be performed if the representation does | |||
exist. | not exist. | |||
A request intended to update a resource (e.g., a PUT) MAY include an | A request intended to update a resource (e.g., a PUT) MAY include an | |||
If-Match header field to signal that the request method MUST NOT be | If-Match header field to signal that the request method MUST NOT be | |||
applied if the representation corresponding to the If-Match value (a | applied if the representation corresponding to the If-Match value (a | |||
single entity-tag) is no longer a representation of that resource. | single entity-tag) is no longer a representation of that resource. | |||
This allows the user to indicate that they do not wish the request to | This allows the user to indicate that they do not wish the request to | |||
be successful if the resource has been changed without their | be successful if the resource has been changed without their | |||
knowledge. Examples: | knowledge. Examples: | |||
If-Match: "xyzzy" | If-Match: "xyzzy" | |||
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | |||
If-Match: * | If-Match: * | |||
The result of a request having both an If-Match header field and | The result of a request having both an If-Match header field and | |||
either an If-None-Match or an If-Modified-Since header fields is | either an If-None-Match or an If-Modified-Since header fields is | |||
undefined by this specification. | undefined by this specification. | |||
6.3. If-Modified-Since | 6.3. If-Modified-Since | |||
The "If-Modified-Since" request-header field is used to make a | The "If-Modified-Since" header field is used to make a request method | |||
request method conditional by date: if the representation that would | conditional by date: if the representation that would have been | |||
have been transferred in a 200 response to a GET request has not been | transferred in a 200 response to a GET request has not been modified | |||
modified since the time specified in this field, then do not perform | since the time specified in this field, then do not perform the | |||
the method; instead, respond as detailed below. | method; instead, respond as detailed below. | |||
If-Modified-Since = "If-Modified-Since" ":" OWS | If-Modified-Since = "If-Modified-Since" ":" OWS | |||
If-Modified-Since-v | If-Modified-Since-v | |||
If-Modified-Since-v = HTTP-date | If-Modified-Since-v = HTTP-date | |||
An example of the field is: | An example of the field is: | |||
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |||
A GET method with an If-Modified-Since header field and no Range | A GET method with an If-Modified-Since header field and no Range | |||
skipping to change at page 16, line 26 | skipping to change at page 16, line 23 | |||
2. If the representation has been modified since the If-Modified- | 2. If the representation has been modified since the If-Modified- | |||
Since date, the response is exactly the same as for a normal GET. | Since date, the response is exactly the same as for a normal GET. | |||
3. If the representation has not been modified since a valid If- | 3. If the representation has not been modified since a valid If- | |||
Modified-Since date, the server SHOULD return a 304 (Not | Modified-Since date, the server SHOULD return a 304 (Not | |||
Modified) response. | Modified) response. | |||
The purpose of this feature is to allow efficient updates of cached | The purpose of this feature is to allow efficient updates of cached | |||
information with a minimum amount of transaction overhead. | information with a minimum amount of transaction overhead. | |||
Note: The Range request-header field modifies the meaning of If- | Note: The Range header field modifies the meaning of If-Modified- | |||
Modified-Since; see Section 5.4 of [Part5] for full details. | Since; see Section 5.4 of [Part5] for full details. | |||
Note: If-Modified-Since times are interpreted by the server, whose | Note: If-Modified-Since times are interpreted by the server, whose | |||
clock might not be synchronized with the client. | clock might not be synchronized with the client. | |||
Note: When handling an If-Modified-Since header field, some | Note: When handling an If-Modified-Since header field, some | |||
servers will use an exact date comparison function, rather than a | servers will use an exact date comparison function, rather than a | |||
less-than function, for deciding whether to send a 304 (Not | less-than function, for deciding whether to send a 304 (Not | |||
Modified) response. To get best results when sending an If- | Modified) response. To get best results when sending an If- | |||
Modified-Since header field for cache validation, clients are | Modified-Since header field for cache validation, clients are | |||
advised to use the exact date string received in a previous Last- | advised to use the exact date string received in a previous Last- | |||
skipping to change at page 17, line 11 | skipping to change at page 17, line 9 | |||
derived from the client's clock without correction to the server's | derived from the client's clock without correction to the server's | |||
clock. Corrections for different time bases between client and | clock. Corrections for different time bases between client and | |||
server are at best approximate due to network latency. | server are at best approximate due to network latency. | |||
The result of a request having both an If-Modified-Since header field | The result of a request having both an If-Modified-Since header field | |||
and either an If-Match or an If-Unmodified-Since header fields is | and either an If-Match or an If-Unmodified-Since header fields is | |||
undefined by this specification. | undefined by this specification. | |||
6.4. If-None-Match | 6.4. If-None-Match | |||
The "If-None-Match" request-header field is used to make a request | The "If-None-Match" header field is used to make a request method | |||
method conditional. A client that has one or more representations | conditional. A client that has one or more representations | |||
previously obtained from the resource can verify that none of those | previously obtained from the resource can verify that none of those | |||
representations is current by including a list of their associated | representations is current by including a list of their associated | |||
entity-tags in the If-None-Match header field. | entity-tags in the If-None-Match header field. | |||
This allows efficient updates of cached information with a minimum | This allows efficient updates of cached information with a minimum | |||
amount of transaction overhead. It is also used to prevent a method | amount of transaction overhead. It is also used to prevent a request | |||
(e.g., PUT) from inadvertently modifying an existing resource when | method (e.g., PUT) from inadvertently modifying an existing resource | |||
the client believes that the resource does not exist. | when the client believes that the resource does not exist. | |||
As a special case, the value "*" matches any current representation | As a special case, the value "*" matches any current representation | |||
of the resource. | of the resource. | |||
If-None-Match = "If-None-Match" ":" OWS If-None-Match-v | If-None-Match = "If-None-Match" ":" OWS If-None-Match-v | |||
If-None-Match-v = "*" / 1#entity-tag | If-None-Match-v = "*" / 1#entity-tag | |||
If any of the entity-tags match the entity-tag of the representation | If any of the entity-tags match the entity-tag of the representation | |||
that would have been returned in the response to a similar GET | that would have been returned in the response to a similar GET | |||
request (without the If-None-Match header field) on that resource, or | request (without the If-None-Match header field) on that resource, or | |||
skipping to change at page 18, line 4 | skipping to change at page 17, line 50 | |||
requested method as if the If-None-Match header field did not exist, | requested method as if the If-None-Match header field did not exist, | |||
but MUST also ignore any If-Modified-Since header field(s) in the | but MUST also ignore any If-Modified-Since header field(s) in the | |||
request. That is, if no entity-tags match, then the server MUST NOT | request. That is, if no entity-tags match, then the server MUST NOT | |||
return a 304 (Not Modified) response. | return a 304 (Not Modified) response. | |||
If the request would, without the If-None-Match header field, result | If the request would, without the If-None-Match header field, result | |||
in anything other than a 2xx or 304 status code, then the If-None- | in anything other than a 2xx or 304 status code, then the If-None- | |||
Match header field MUST be ignored. (See Section 5 for a discussion | Match header field MUST be ignored. (See Section 5 for a discussion | |||
of server behavior when both If-Modified-Since and If-None-Match | of server behavior when both If-Modified-Since and If-None-Match | |||
appear in the same request.) | appear in the same request.) | |||
The meaning of "If-None-Match: *" is that the method MUST NOT be | ||||
performed if the representation selected by the origin server (or by | The meaning of "If-None-Match: *" is that the request method MUST NOT | |||
a cache, possibly using the Vary mechanism, see Section 3.5 of | be performed if the representation selected by the origin server (or | |||
by a cache, possibly using the Vary mechanism, see Section 3.5 of | ||||
[Part6]) exists, and SHOULD be performed if the representation does | [Part6]) exists, and SHOULD be performed if the representation does | |||
not exist. This feature is intended to be useful in preventing races | not exist. This feature is intended to be useful in preventing races | |||
between PUT operations. | between PUT operations. | |||
Examples: | Examples: | |||
If-None-Match: "xyzzy" | If-None-Match: "xyzzy" | |||
If-None-Match: W/"xyzzy" | If-None-Match: W/"xyzzy" | |||
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | |||
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" | |||
If-None-Match: * | If-None-Match: * | |||
The result of a request having both an If-None-Match header field and | The result of a request having both an If-None-Match header field and | |||
either an If-Match or an If-Unmodified-Since header fields is | either an If-Match or an If-Unmodified-Since header fields is | |||
undefined by this specification. | undefined by this specification. | |||
6.5. If-Unmodified-Since | 6.5. If-Unmodified-Since | |||
The "If-Unmodified-Since" request-header field is used to make a | The "If-Unmodified-Since" header field is used to make a request | |||
request method conditional. If the representation that would have | method conditional. If the representation that would have been | |||
been transferred in a 200 response to a GET request on the same | transferred in a 200 response to a GET request on the same resource | |||
resource has not been modified since the time specified in this | has not been modified since the time specified in this field, the | |||
field, the server SHOULD perform the requested operation as if the | server SHOULD perform the requested operation as if the If- | |||
If-Unmodified-Since header field were not present. | Unmodified-Since header field were not present. | |||
If the representation has been modified since the specified time, the | If the representation has been modified since the specified time, the | |||
server MUST NOT perform the requested operation, and MUST return a | server MUST NOT perform the requested operation, and MUST return a | |||
412 (Precondition Failed). | 412 (Precondition Failed). | |||
If-Unmodified-Since = "If-Unmodified-Since" ":" OWS | If-Unmodified-Since = "If-Unmodified-Since" ":" OWS | |||
If-Unmodified-Since-v | If-Unmodified-Since-v | |||
If-Unmodified-Since-v = HTTP-date | If-Unmodified-Since-v = HTTP-date | |||
An example of the field is: | An example of the field is: | |||
skipping to change at page 19, line 18 | skipping to change at page 19, line 17 | |||
The "Last-Modified" header field indicates the date and time at which | The "Last-Modified" header field indicates the date and time at which | |||
the origin server believes the representation was last modified. | the origin server believes the representation was last modified. | |||
Last-Modified = "Last-Modified" ":" OWS Last-Modified-v | Last-Modified = "Last-Modified" ":" OWS Last-Modified-v | |||
Last-Modified-v = HTTP-date | Last-Modified-v = HTTP-date | |||
An example of its use is | An example of its use is | |||
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | |||
The exact meaning of this header field depends on the implementation | A representation is typically the sum of many parts behind the | |||
of the origin server and the nature of the original resource. For | resource interface. The last-modified time would usually be the most | |||
files, it might be just the file system last-modified time. For | recent time that any of those parts were changed. How that value is | |||
representations with dynamically included parts, it might be the most | determined for any given resource is an implementation detail beyond | |||
recent of the set of last-modify times for its component parts. For | the scope of this specification. What matters to HTTP is how | |||
database gateways, it might be the last-update time stamp of the | recipients of the Last-Modified header field can use its value to | |||
record. For virtual objects, it might be the last time the internal | make conditional requests and test the validity of locally cached | |||
state changed. | responses. | |||
An origin server MUST NOT send a Last-Modified date which is later | An origin server MUST NOT send a Last-Modified date which is later | |||
than the server's time of message origination. In such cases, where | than the server's time of message origination. In such cases, where | |||
the resource's last modification would indicate some time in the | the resource's last modification would indicate some time in the | |||
future, the server MUST replace that date with the message | future, the server MUST replace that date with the message | |||
origination date. | origination date. | |||
An origin server SHOULD obtain the Last-Modified value of the | An origin server SHOULD obtain the Last-Modified value of the | |||
representation as close as possible to the time that it generates the | representation as close as possible to the time that it generates the | |||
Date value of its response. This allows a recipient to make an | Date value of its response. This allows a recipient to make an | |||
skipping to change at page 20, line 51 | skipping to change at page 20, line 46 | |||
9. Acknowledgments | 9. Acknowledgments | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-12 | and Message Parsing", draft-ietf-httpbis-p1-messaging-13 | |||
(work in progress), October 2010. | (work in progress), March 2011. | |||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | |||
and Content Negotiation", draft-ietf-httpbis-p3-payload-12 | and Content Negotiation", draft-ietf-httpbis-p3-payload-13 | |||
(work in progress), October 2010. | (work in progress), March 2011. | |||
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | |||
Partial Responses", draft-ietf-httpbis-p5-range-12 (work | Partial Responses", draft-ietf-httpbis-p5-range-13 (work | |||
in progress), October 2010. | in progress), March 2011. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | |||
6: Caching", draft-ietf-httpbis-p6-cache-12 (work in | 6: Caching", draft-ietf-httpbis-p6-cache-13 (work in | |||
progress), October 2010. | progress), March 2011. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
10.2. Informative References | 10.2. Informative References | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
skipping to change at page 25, line 22 | skipping to change at page 25, line 22 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify | |||
entity / representation / variant terminology" | entity / representation / variant terminology" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider | |||
removing the 'changes from 2068' sections" | removing the 'changes from 2068' sections" | |||
C.13. Since draft-ietf-httpbis-p4-conditional-11 | C.13. Since draft-ietf-httpbis-p4-conditional-11 | |||
None. | None. | |||
C.14. Since draft-ietf-httpbis-p4-conditional-12 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header | ||||
Classification" | ||||
Index | Index | |||
3 | 3 | |||
304 Not Modified (status code) 8 | 304 Not Modified (status code) 8 | |||
4 | 4 | |||
412 Precondition Failed (status code) 8 | 412 Precondition Failed (status code) 8 | |||
E | E | |||
ETag header 13 | ETag header field 13 | |||
G | G | |||
Grammar | Grammar | |||
entity-tag 6 | entity-tag 6 | |||
ETag 13 | ETag 13 | |||
ETag-v 13 | ETag-v 13 | |||
If-Match 14 | If-Match 14 | |||
If-Match-v 14 | If-Match-v 14 | |||
If-Modified-Since 15 | If-Modified-Since 15 | |||
If-Modified-Since-v 15 | If-Modified-Since-v 15 | |||
If-None-Match 17 | If-None-Match 17 | |||
If-None-Match-v 17 | If-None-Match-v 17 | |||
If-Unmodified-Since 18 | If-Unmodified-Since 18 | |||
If-Unmodified-Since-v 18 | If-Unmodified-Since-v 18 | |||
Last-Modified 19 | Last-Modified 19 | |||
Last-Modified-v 19 | Last-Modified-v 19 | |||
opaque-tag 6 | opaque-tag 6 | |||
weak 6 | weak 6 | |||
H | H | |||
Headers | Header Fields | |||
ETag 13 | ETag 13 | |||
If-Match 14 | If-Match 14 | |||
If-Modified-Since 15 | If-Modified-Since 15 | |||
If-None-Match 17 | If-None-Match 17 | |||
If-Unmodified-Since 18 | If-Unmodified-Since 18 | |||
Last-Modified 19 | Last-Modified 19 | |||
I | I | |||
If-Match header 14 | If-Match header field 14 | |||
If-Modified-Since header 15 | If-Modified-Since header field 15 | |||
If-None-Match header 17 | If-None-Match header field 17 | |||
If-Unmodified-Since header 18 | If-Unmodified-Since header field 18 | |||
L | L | |||
Last-Modified header 19 | Last-Modified header field 19 | |||
S | S | |||
Status Codes | Status Codes | |||
304 Not Modified 8 | 304 Not Modified 8 | |||
412 Precondition Failed 8 | 412 Precondition Failed 8 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Day Software | Adobe Systems Incorporated | |||
23 Corporate Plaza DR, Suite 280 | 345 Park Ave | |||
Newport Beach, CA 92660 | San Jose, CA 95110 | |||
USA | USA | |||
Phone: +1-949-706-5300 | ||||
Fax: +1-949-706-5305 | ||||
EMail: fielding@gbiv.com | EMail: fielding@gbiv.com | |||
URI: http://roy.gbiv.com/ | URI: http://roy.gbiv.com/ | |||
Jim Gettys | Jim Gettys | |||
Alcatel-Lucent Bell Labs | Alcatel-Lucent Bell Labs | |||
21 Oak Knoll Road | 21 Oak Knoll Road | |||
Carlisle, MA 01741 | Carlisle, MA 01741 | |||
USA | USA | |||
EMail: jg@freedesktop.org | EMail: jg@freedesktop.org | |||
URI: http://gettys.wordpress.com/ | URI: http://gettys.wordpress.com/ | |||
Jeffrey C. Mogul | Jeffrey C. Mogul | |||
Hewlett-Packard Company | Hewlett-Packard Company | |||
HP Labs, Large Scale Systems Group | HP Labs, Large Scale Systems Group | |||
1501 Page Mill Road, MS 1177 | 1501 Page Mill Road, MS 1177 | |||
Palo Alto, CA 94304 | Palo Alto, CA 94304 | |||
USA | USA | |||
EMail: JeffMogul@acm.org | EMail: JeffMogul@acm.org | |||
Henrik Frystyk Nielsen | Henrik Frystyk Nielsen | |||
skipping to change at page 27, line 22 | skipping to change at page 27, line 31 | |||
Henrik Frystyk Nielsen | Henrik Frystyk Nielsen | |||
Microsoft Corporation | Microsoft Corporation | |||
1 Microsoft Way | 1 Microsoft Way | |||
Redmond, WA 98052 | Redmond, WA 98052 | |||
USA | USA | |||
EMail: henrikn@microsoft.com | EMail: henrikn@microsoft.com | |||
Larry Masinter | Larry Masinter | |||
Adobe Systems, Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
San Jose, CA 95110 | San Jose, CA 95110 | |||
USA | USA | |||
EMail: LMM@acm.org | EMail: LMM@acm.org | |||
URI: http://larry.masinter.net/ | URI: http://larry.masinter.net/ | |||
Paul J. Leach | Paul J. Leach | |||
Microsoft Corporation | Microsoft Corporation | |||
1 Microsoft Way | 1 Microsoft Way | |||
End of changes. 39 change blocks. | ||||
84 lines changed or deleted | 89 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |