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/