draft-ietf-httpbis-p4-conditional-01.txt   draft-ietf-httpbis-p4-conditional-02.txt 
Network Working Group R. Fielding, Ed. Network Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: July 15, 2008 J. Mogul Expires: August 27, 2008 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
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
January 12, 2008 February 24, 2008
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-01 draft-ietf-httpbis-p4-conditional-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
This draft incorporates those issue resolutions that were either This draft incorporates those issue resolutions that were either
collected in the original RFC2616 errata list collected in the original RFC2616 errata list
(<http://purl.org/NET/http-errata>), or which were agreed upon on the (<http://purl.org/NET/http-errata>), or which were agreed upon on the
mailing list between October 2006 and November 2007 (as published in mailing list between October 2006 and November 2007 (as published in
"draft-lafon-rfc2616bis-03"). "draft-lafon-rfc2616bis-03").
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5
4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6
5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 5. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9
6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11
6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 12 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13
6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 15 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14
6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Compatibility with Previous Versions . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17 Appendix A. Compatibility with Previous Versions . . . . . . . . 18
A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 17 publication) . . . . . . . . . . . . . . . . . . . . 18
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 18
B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 18 B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 18
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 23
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
skipping to change at page 4, line 43 skipping to change at page 4, line 43
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the MUST or
REQUIRED level and all the SHOULD level requirements for its REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant."
2. Entity Tags 2. Notational Conventions and Generic Grammar
This specification uses the ABNF syntax defined in Section 2.1 of
[Part1] and the core rules defined in Section 2.2 of [Part1]:
[[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
quoted-string = <quoted-string, defined in [Part1], Section 2.2>
The ABNF rules below are defined in other parts:
HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
3. Entity Tags
Entity tags are used for comparing two or more entities from the same Entity tags are used for comparing two or more entities from the same
requested resource. HTTP/1.1 uses entity tags in the ETag requested resource. HTTP/1.1 uses entity tags in the ETag
(Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4), (Section 7.1), If-Match (Section 7.2), If-None-Match (Section 7.4),
and If-Range (Section 5.3 of [Part5]) header fields. The definition and If-Range (Section 6.3 of [Part5]) header fields. The definition
of how they are used and compared as cache validators is in of how they are used and compared as cache validators is in
Section 4. An entity tag consists of an opaque quoted string, Section 5. An entity tag consists of an opaque quoted string,
possibly prefixed by a weakness indicator. possibly prefixed by a weakness indicator.
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = "W/" weak = "W/"
opaque-tag = quoted-string opaque-tag = quoted-string
A "strong entity tag" MAY be shared by two entities of a resource A "strong entity tag" MAY be shared by two entities of a resource
only if they are equivalent by octet equality. only if they are equivalent by octet equality.
A "weak entity tag," indicated by the "W/" prefix, MAY be shared by A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
skipping to change at page 5, line 24 skipping to change at page 5, line 37
could be substituted for each other with no significant change in could be substituted for each other with no significant change in
semantics. A weak entity tag can only be used for weak comparison. semantics. A weak entity tag can only be used for weak comparison.
An entity tag MUST be unique across all versions of all entities An entity tag MUST be unique across all versions of all entities
associated with a particular resource. A given entity tag value MAY associated with a particular resource. A given entity tag value MAY
be used for entities obtained by requests on different URIs. The use be used for entities obtained by requests on different URIs. The use
of the same entity tag value in conjunction with entities obtained by of the same entity tag value in conjunction with entities obtained by
requests on different URIs does not imply the equivalence of those requests on different URIs does not imply the equivalence of those
entities. entities.
3. Status Code Definitions 4. Status Code Definitions
3.1. 304 Not Modified 4.1. 304 Not Modified
If the client has performed a conditional GET request and access is If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line message-body, and thus is always terminated by the first empty line
after the header fields. after the header fields.
The response MUST include the following header fields: The response MUST include the following header fields:
o Date, unless its omission is required by Section 8.3.1 of [Part1] o Date, unless its omission is required by Section 8.3.1 of [Part1]
skipping to change at page 5, line 50 skipping to change at page 6, line 19
already specified by [RFC2068], Section 14.19), caches will operate already specified by [RFC2068], Section 14.19), caches will operate
correctly. correctly.
o ETag and/or Content-Location, if the header would have been sent o ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request in a 200 response to the same request
o Expires, Cache-Control, and/or Vary, if the field-value might o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant variant
If the conditional GET used a strong cache validator (see Section 4), If the conditional GET used a strong cache validator (see Section 5),
the response SHOULD NOT include other entity-headers. Otherwise the response SHOULD NOT include other entity-headers. Otherwise
(i.e., the conditional GET used a weak validator), the response MUST (i.e., the conditional GET used a weak validator), the response MUST
NOT include other entity-headers; this prevents inconsistencies NOT include other entity-headers; this prevents inconsistencies
between cached entity-bodies and updated headers. between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the cache MUST 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 4.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 request-header fields
evaluated to false when it was tested on the server. This response evaluated to false when it was tested on the server. This response
code allows the client to place preconditions on the current resource code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested metainformation (header field data) and thus prevent the requested
method from being applied to a resource other than the one intended. method from being applied to a resource other than the one intended.
4. Weak and Strong Validators 5. 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 entities, one normally decide if they represent the same or different entities, one normally
would expect that if the entity (the entity-body or any entity- would expect that if the entity (the entity-body or any entity-
headers) changes in any way, then the associated validator would headers) changes in any way, then the associated validator would
change as well. If this is true, then we call this validator a change as well. If this is true, then we call this validator a
"strong validator." "strong validator."
However, there might be cases when a server prefers to change the However, there might be cases when a server prefers to change the
validator only on semantically significant changes, and not when validator only on semantically significant changes, and not when
skipping to change at page 7, line 30 skipping to change at page 7, line 44
only usable in contexts that do not depend on exact equality of an only usable in contexts that do not depend on exact equality of an
entity. For example, either kind is usable for a conditional GET of entity. For example, either kind is usable for a conditional GET of
a full entity. However, only a strong validator is usable for a sub- a full entity. However, only a strong validator is usable for a sub-
range retrieval, since otherwise the client might end up with an range retrieval, since otherwise the client might end up with an
internally inconsistent entity. internally inconsistent entity.
Clients MAY issue simple (non-subrange) GET requests with either weak Clients MAY issue simple (non-subrange) GET requests with either weak
validators or strong validators. Clients MUST NOT use weak validators or strong validators. Clients MUST NOT use weak
validators in other forms of request. validators in other forms of request.
The only function that the HTTP/1.1 protocol defines on validators is The only function that HTTP/1.1 defines on validators is comparison.
comparison. There are two validator comparison functions, depending There are two validator comparison functions, depending on whether
on whether the comparison context allows the use of weak validators the comparison context allows the use of weak validators or not:
or not:
o The strong comparison function: in order to be considered equal, o The strong comparison function: in order to be considered equal,
both validators MUST be identical in every way, and both MUST NOT both validators MUST be identical in every way, and both MUST NOT
be weak. be weak.
o The weak comparison function: in order to be considered equal, o The weak comparison function: in order to be considered equal,
both validators MUST be identical in every way, but either or both both validators MUST be identical in every way, but either or both
of them MAY be tagged as "weak" without affecting the result. of them MAY be tagged as "weak" without affecting the result.
An entity tag is strong unless it is explicitly tagged as weak. An entity tag is strong unless it is explicitly tagged as weak.
Section 2 gives the syntax for entity tags. Section 3 gives the syntax for entity tags.
A Last-Modified time, when used as a validator in a request, is A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong, implicitly weak unless it is possible to deduce that it is strong,
using the following rules: using the following rules:
o The validator is being compared by an origin server to the actual o The validator is being compared by an origin server to the actual
current validator for the entity and, current validator for the entity and,
o That origin server reliably knows that the associated entity did o That origin server reliably knows that the associated entity did
not change twice during the second covered by the presented not change twice during the second covered by the presented
validator. validator.
or or
o The validator is about to be used by a client in an If-Modified- o The validator is about to be used by a client in an If-Modified-
Since or If-Unmodified-Since header, because the client has a Since or If-Unmodified-Since header, because the client has a
cache entry for the associated entity, and cache entry for the associated entity, and
skipping to change at page 9, line 6 skipping to change at page 9, line 20
described here. described here.
A cache or origin server receiving a conditional request, other than A cache or origin server receiving a conditional request, other than
a full-body GET request, MUST use the strong comparison function to a full-body GET request, MUST use the strong comparison function to
evaluate the condition. evaluate the condition.
These rules allow HTTP/1.1 caches and clients to safely perform sub- These rules allow HTTP/1.1 caches and clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0 range retrievals on values that have been obtained from HTTP/1.0
servers. servers.
5. Rules for When to Use Entity Tags and Last-Modified Dates 6. Rules for When to Use Entity Tags and Last-Modified Dates
We adopt a set of rules and recommendations for origin servers, We adopt a set of rules and recommendations for origin servers,
clients, and caches regarding when various validator types ought to clients, and caches regarding when various validator types ought to
be used, and for what purposes. be used, and for what purposes.
HTTP/1.1 origin servers: HTTP/1.1 origin servers:
o SHOULD send an entity tag validator unless it is not feasible to o SHOULD send an entity tag validator unless it is not feasible to
generate one. generate one.
skipping to change at page 10, line 44 skipping to change at page 11, line 10
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 will 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 7. 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.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
6.1. ETag 7.1. ETag
The ETag response-header field provides the current value of the The ETag response-header field provides the current value of the
entity tag for the requested variant. The headers used with entity entity tag for the requested variant. The headers used with entity
tags are described in Sections 6.2 and 6.4 of this document, and in tags are described in Sections 7.2 and 7.4 of this document, and in
Section 5.3 of [Part5]. The entity tag MAY be used for comparison Section 6.3 of [Part5]. The entity tag MAY be used for comparison
with other entities from the same resource (see Section 4). with other entities from the same resource (see Section 5).
ETag = "ETag" ":" entity-tag ETag = "ETag" ":" entity-tag
Examples: Examples:
ETag: "xyzzy" ETag: "xyzzy"
ETag: W/"xyzzy" ETag: W/"xyzzy"
ETag: "" ETag: ""
6.2. If-Match The ETag response-header field value, an entity tag, provides for an
"opaque" cache validator. This might allow more reliable validation
in situations where it is inconvenient to store modification dates,
where the one-second resolution of HTTP date values is not
sufficient, or where the origin server wishes to avoid certain
paradoxes that might arise from the use of modification dates.
The principle behind entity tags is that only the service author
knows the semantics of a resource well enough to select an
appropriate cache validation mechanism, and the specification of any
validator comparison function more complex than byte-equality would
open up a can of worms. Thus, comparisons of any other headers
(except Last-Modified, for compatibility with HTTP/1.0) are never
used for purposes of validating a cache entry.
7.2. If-Match
The If-Match request-header field is used with a method to make it The If-Match request-header field is used with a method to make it
conditional. A client that has one or more entities previously conditional. A client that has one or more entities previously
obtained from the resource can verify that one of those entities is obtained from the resource can verify that one of those entities is
current by including a list of their associated entity tags in the current by including a list of their associated entity tags in the
If-Match header field. Entity tags are defined in Section 2. The If-Match header field. Entity tags are defined in Section 3. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. It is information with a minimum amount of transaction overhead. It is
also used, on updating requests, to prevent inadvertent modification also used, on updating requests, to prevent inadvertent modification
of the wrong version of a resource. As a special case, the value "*" of the wrong version of a resource. As a special case, the value "*"
matches any current entity of the resource. matches any current entity of the resource.
If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
If any of the entity tags match the entity tag of the entity that If any of the entity tags match the entity tag of the entity that
would have been returned in the response to a similar GET request would have been returned in the response to a similar GET request
(without the If-Match header) on that resource, or if "*" is given (without the If-Match header) on that resource, or if "*" is given
and any current entity exists for that resource, then the server MAY and any current entity exists for that resource, then the server MAY
perform the requested method as if the If-Match header field did not perform the requested method as if the If-Match header field did not
exist. exist.
A server MUST use the strong comparison function (see Section 4) to A server MUST use the strong comparison function (see Section 5) to
compare the entity tags in If-Match. compare the entity tags in If-Match.
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
entity exists, the server MUST NOT perform the requested method, and entity exists, the server MUST NOT perform the requested method, and
MUST return a 412 (Precondition Failed) response. This behavior is MUST return a 412 (Precondition Failed) response. This behavior is
most useful when the client wants to prevent an updating method, such most useful when the client wants to prevent an updating method, such
as PUT, from modifying a resource that has changed since the client as PUT, from modifying a resource that has changed since the client
last retrieved it. 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, then the If-Match header anything other than a 2xx or 412 status, then the If-Match header
MUST be ignored. MUST be ignored.
The meaning of "If-Match: *" is that the method SHOULD be performed The meaning of "If-Match: *" is that the method SHOULD be performed
if the representation selected by the origin server (or by a cache, if the representation selected by the origin server (or by a cache,
possibly using the Vary mechanism, see Section 15.5 of [Part6]) possibly using the Vary mechanism, see Section 16.5 of [Part6])
exists, and MUST NOT be performed if the representation does not exists, and MUST NOT be performed if the representation does not
exist. 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 entity corresponding to the If-Match value (a single applied if the entity corresponding to the If-Match value (a single
entity tag) is no longer a representation of that resource. This entity tag) is no longer a representation of that resource. This
allows the user to indicate that they do not wish the request to be allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. successful if the resource has been changed without their knowledge.
Examples: 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.
skipping to change at page 12, line 32 skipping to change at page 13, line 15
Examples: 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 7.3. If-Modified-Since
The If-Modified-Since request-header field is used with a method to The If-Modified-Since request-header field is used with a method to
make it conditional: if the requested variant has not been modified make it conditional: if the requested variant has not been modified
since the time specified in this field, an entity will not be since the time specified in this field, an entity will not be
returned from the server; instead, a 304 (Not Modified) response will returned from the server; instead, a 304 (Not Modified) response will
be returned without any message-body. be returned without any message-body.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date If-Modified-Since = "If-Modified-Since" ":" HTTP-date
An example of the field is: An example of the field is:
skipping to change at page 13, line 21 skipping to change at page 13, line 50
date, the response is exactly the same as for a normal GET. date, the response is exactly the same as for a normal GET.
3. If the variant has not been modified since a valid If-Modified- 3. If the variant 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. 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 request-header field modifies the meaning of If-
Modified-Since; see Section 5.4 of [Part5] for full details. Modified-Since; see Section 6.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 14, line 5 skipping to change at page 14, line 35
possibility of clock-skew-related problems if the If-Modified- possibility of clock-skew-related problems if the If-Modified-
Since date is derived from the client's clock without correction Since date is derived from the client's clock without correction
to the server's clock. Corrections for different time bases to the server's clock. Corrections for different time bases
between client and server are at best approximate due to network between client and server are at best approximate due to network
latency. 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 7.4. If-None-Match
The If-None-Match request-header field is used with a method to make The If-None-Match request-header field is used with a method to make
it conditional. A client that has one or more entities previously it conditional. A client that has one or more entities previously
obtained from the resource can verify that none of those entities is obtained from the resource can verify that none of those entities is
current by including a list of their associated entity tags in the current by including a list of their associated entity tags in the
If-None-Match header field. The purpose of this feature is to allow If-None-Match header field. The purpose of this feature is to allow
efficient updates of cached information with a minimum amount of efficient updates of cached information with a minimum amount of
transaction overhead. It is also used to prevent a method (e.g. transaction overhead. It is also used to prevent a method (e.g.
PUT) from inadvertently modifying an existing resource when the PUT) from inadvertently modifying an existing resource when the
client believes that the resource does not exist. client believes that the resource does not exist.
skipping to change at page 14, line 35 skipping to change at page 15, line 16
given and any current entity exists for that resource, then the given and any current entity exists for that resource, then the
server MUST NOT perform the requested method, unless required to do server MUST NOT perform the requested method, unless required to do
so because the resource's modification date fails to match that so because the resource's modification date fails to match that
supplied in an If-Modified-Since header field in the request. supplied in an If-Modified-Since header field in the request.
Instead, if the request method was GET or HEAD, the server SHOULD Instead, if the request method was GET or HEAD, the server SHOULD
respond with a 304 (Not Modified) response, including the cache- respond with a 304 (Not Modified) response, including the cache-
related header fields (particularly ETag) of one of the entities that related header fields (particularly ETag) of one of the entities that
matched. For all other request methods, the server MUST respond with matched. For all other request methods, the server MUST respond with
a status of 412 (Precondition Failed). a status of 412 (Precondition Failed).
See Section 4 for rules on how to determine if two entities tags See Section 5 for rules on how to determine if two entities tags
match. The weak comparison function can only be used with GET or match. The weak comparison function can only be used with GET or
HEAD requests. HEAD requests.
If none of the entity tags match, then the server MAY perform the If none of the entity tags match, then the server MAY perform the
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, then the If-None-Match in anything other than a 2xx or 304 status, then the If-None-Match
header MUST be ignored. (See Section 5 for a discussion of server header MUST be ignored. (See Section 6 for a discussion of server
behavior when both If-Modified-Since and If-None-Match appear in the behavior when both If-Modified-Since and If-None-Match appear in the
same request.) same request.)
The meaning of "If-None-Match: *" is that the method MUST NOT be The meaning of "If-None-Match: *" is that the method MUST NOT be
performed if the representation selected by the origin server (or by performed if the representation selected by the origin server (or by
a cache, possibly using the Vary mechanism, see Section 15.5 of a cache, possibly using the Vary mechanism, see Section 16.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 7.5. If-Unmodified-Since
The If-Unmodified-Since request-header field is used with a method to The If-Unmodified-Since request-header field is used with a method to
make it conditional. If the requested resource has not been modified make it conditional. If the requested resource has not been modified
since the time specified in this field, the server SHOULD perform the since the time specified in this field, the server SHOULD perform the
requested operation as if the If-Unmodified-Since header were not requested operation as if the If-Unmodified-Since header were not
present. present.
If the requested variant has been modified since the specified time, If the requested variant has been modified since the specified time,
the server MUST NOT perform the requested operation, and MUST return the server MUST NOT perform the requested operation, and MUST return
a 412 (Precondition Failed). a 412 (Precondition Failed).
skipping to change at page 16, line 5 skipping to change at page 16, line 33
If the request normally (i.e., without the If-Unmodified-Since If the request normally (i.e., without the If-Unmodified-Since
header) would result in anything other than a 2xx or 412 status, the header) would result in anything other than a 2xx or 412 status, the
If-Unmodified-Since header SHOULD be ignored. If-Unmodified-Since header SHOULD be ignored.
If the specified date is invalid, the header is ignored. If the specified date is invalid, the header is ignored.
The result of a request having both an If-Unmodified-Since header The result of a request having both an If-Unmodified-Since header
field and either an If-None-Match or an If-Modified-Since header field and either an If-None-Match or an If-Modified-Since header
fields is undefined by this specification. fields is undefined by this specification.
6.6. Last-Modified 7.6. Last-Modified
The Last-Modified entity-header field indicates the date and time at The Last-Modified entity-header field indicates the date and time at
which the origin server believes the variant was last modified. which the origin server believes the variant was last modified.
Last-Modified = "Last-Modified" ":" HTTP-date Last-Modified = "Last-Modified" ":" 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
skipping to change at page 16, line 39 skipping to change at page 17, line 19
origination date. origination date.
An origin server SHOULD obtain the Last-Modified value of the entity An origin server SHOULD obtain the Last-Modified value of the entity
as close as possible to the time that it generates the Date value of as close as possible to the time that it generates the Date value of
its response. This allows a recipient to make an accurate assessment its response. This allows a recipient to make an accurate assessment
of the entity's modification time, especially if the entity changes of the entity's modification time, especially if the entity changes
near the time that the response is generated. near the time that the response is generated.
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
7. IANA Considerations The Last-Modified entity-header field value is often used as a cache
validator. In simple terms, a cache entry is considered to be valid
if the entity has not been modified since the Last-Modified value.
TBD. 8. IANA Considerations
8. Security Considerations [[anchor2: TBD.]]
9. Security Considerations
No additional security considerations have been identified beyond No additional security considerations have been identified beyond
those applicable to HTTP in general [Part1]. those applicable to HTTP in general [Part1].
9. Acknowledgments 10. Acknowledgments
10. References 11. References
10.1. Normative References 11.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-01 and Message Parsing", draft-ietf-httpbis-p1-messaging-02
(work in progress), January 2008. (work in progress), February 2008.
[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-01 (work Partial Responses", draft-ietf-httpbis-p5-range-02 (work
in progress), January 2008. in progress), February 2008.
[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.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-01 (work in progress), draft-ietf-httpbis-p6-cache-02 (work in progress),
January 2008. February 2008.
[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.
10.2. Informative References 11.2. Informative References
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Appendix A. Compatibility with Previous Versions Appendix A. Compatibility with Previous Versions
skipping to change at page 18, line 16 skipping to change at page 18, line 45
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
and Informative references" and Informative references"
Other changes: Other changes:
o Move definitions of 304 and 412 condition codes from Part2. o Move definitions of 304 and 412 condition codes from Part2.
B.3. Since draft-ietf-httpbis-p4-conditional-01
Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Add explicit references to BNF syntax and rules imported from
other parts of the specification.
Index Index
3 3
304 Not Modified (status code) 5 304 Not Modified (status code) 5
4 4
412 Precondition Failed (status code) 6 412 Precondition Failed (status code) 6
E E
ETag header 11 ETag header 11
G G
Grammar Grammar
entity-tag 5 entity-tag 5
ETag 11 ETag 11
If-Match 11 If-Match 12
If-Modified-Since 12 If-Modified-Since 13
If-None-Match 14 If-None-Match 14
If-Unmodified-Since 15 If-Unmodified-Since 16
Last-Modified 16 Last-Modified 16
opaque-tag 5 opaque-tag 5
weak 5 weak 5
H H
Headers Headers
ETag 11 ETag 11
If-Match 11 If-Match 12
If-Modified-Since 12 If-Modified-Since 13
If-None-Match 14 If-None-Match 14
If-Unmodified-Since 15 If-Unmodified-Since 16
Last-Modified 16 Last-Modified 16
I I
If-Match header 11 If-Match header 12
If-Modified-Since header 12 If-Modified-Since header 13
If-None-Match header 14 If-None-Match header 14
If-Unmodified-Since header 15 If-Unmodified-Since header 16
L L
Last-Modified header 16 Last-Modified header 16
S S
Status Codes Status Codes
304 Not Modified 5 304 Not Modified 5
412 Precondition Failed 6 412 Precondition Failed 6
Authors' Addresses Authors' Addresses
 End of changes. 52 change blocks. 
84 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/