draft-ietf-httpbis-p4-conditional-07.txt   draft-ietf-httpbis-p4-conditional-08.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis 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: January 14, 2010 J. Mogul Expires: April 29, 2010 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
July 13, 2009 October 26, 2009
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-07 draft-ietf-httpbis-p4-conditional-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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."
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 January 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 42 skipping to change at page 2, line 42
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/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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.8. The changes in this draft are summarized in Appendix C.9.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 5 Specification . . . . . . . . . . . . . . . . . . . . 5
2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 27 skipping to change at page 3, line 27
4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7
5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11
6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13
6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15
6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. Message Header Registration . . . . . . . . . . . . . . . 17 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 17
7.2. Message Header Registration . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Compatibility with Previous Versions . . . . . . . . 19 Appendix A. Compatibility with Previous Versions . . . . . . . . 19
A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 20
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20
C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21 C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21
C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21 C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21
C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21 C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21
C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21 C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21
C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22 C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22
C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22 C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22
C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22 C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22
C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 5, line 19 skipping to change at page 5, line 19
The core rules below are defined in Section 1.2.2 of [Part1]: The core rules below are defined in Section 1.2.2 of [Part1]:
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
1.2.2. ABNF Rules defined in other Parts of the Specification 1.2.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
2. Entity Tags 2. 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 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4),
and If-Range (Section 5.3 of [Part5]) header fields. The definition and If-Range (Section 5.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 4. An entity tag consists of an opaque quoted string,
possibly prefixed by a weakness indicator. possibly prefixed by a weakness indicator.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
3.1. 304 Not Modified 3.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 9.3.1 of [Part1].
If a clockless origin server obeys these rules, and proxies and If a clockless origin server obeys these rules, and proxies and
clients add their own Date to any response received without one clients add their own Date to any response received without one
(as already specified by Section 8.3 of [Part1], caches will (as already specified by Section 9.3 of [Part1], caches will
operate correctly. operate 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 4),
skipping to change at page 8, line 14 skipping to change at page 8, line 14
The only function that HTTP/1.1 defines on validators is comparison. The only function that HTTP/1.1 defines on validators is comparison.
There are two validator comparison functions, depending on whether There are two validator comparison functions, depending on whether
the comparison context allows the use of weak validators or not: the comparison context allows the use of weak validators 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 opaque-tags MUST be identical character-by-character, and both opaque-tags MUST be identical character-by-character, and
both MUST NOT be weak. both MUST NOT 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 opaque-tags MUST be identical character-by-character. both opaque-tags MUST be identical character-by-character, but
either or both of them MAY be tagged as "weak" without affecting
the result.
The example below shows the results for a set of entity tag pairs, The example below shows the results for a set of entity tag pairs,
and both the weak and strong comparison function results: and both the weak and strong comparison function results:
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match | | W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match | | W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match | | W/"1" | "1" | no match | match |
skipping to change at page 11, line 39 skipping to change at page 11, line 41
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 6.1. ETag
The response-header field "ETag" provides the current value of the The "ETag" response-header field provides the current value of the
entity tag (see Section 2) for the requested variant. The headers entity tag (see Section 2) for the requested variant, which may be
used with entity tags are described in Sections 6.2 and 6.4 of this used for comparison with other entities from the same resource (see
document, and in Section 5.3 of [Part5]. The entity tag MAY be used
for comparison with other entities from the same resource (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 12, line 28 skipping to change at page 12, 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 headers open up a can of worms. Thus, comparisons of any other headers
(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 request-header field "If-Match" is used with a method to make it The "If-Match" request-header field is used to make a request method
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.
purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. It is This allows efficient updates of cached information with a minimum
also used, on updating requests, to prevent inadvertent modification amount of transaction overhead. It is also used when updating
of the wrong version of a resource. As a special case, the value "*" resources, to prevent inadvertent modification of the wrong version
matches any current entity of the resource. of a resource. As a special case, the value "*" matches any current
entity of the resource.
If-Match = "If-Match" ":" OWS If-Match-v If-Match = "If-Match" ":" OWS If-Match-v
If-Match-v = "*" / 1#entity-tag If-Match-v = "*" / 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
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.
skipping to change at page 13, line 38 skipping to change at page 13, line 36
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 request-header field "If-Modified-Since" is used with a method to The "If-Modified-Since" request-header field is used to make a
make it conditional: if the requested variant has not been modified request method conditional: if the requested variant has not been
since the time specified in this field, an entity will not be modified since the time specified in this field, the server will not
returned from the server; instead, a 304 (Not Modified) response will return an entity; instead, a 304 (Not Modified) response will be
be returned without any message-body. returned.
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 and no Range header A GET method with an If-Modified-Since header and no Range header
skipping to change at page 15, line 11 skipping to change at page 15, line 9
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 6.4. If-None-Match
The request-header field "If-None-Match" is used with a method to The "If-None-Match" request-header field is used to make a request
make it conditional. A client that has one or more entities method conditional. A client that has one or more entities
previously obtained from the resource can verify that none of those previously obtained from the resource can verify that none of those
entities is current by including a list of their associated entity entities is current by including a list of their associated entity
tags in the If-None-Match header field. The purpose of this feature tags in the If-None-Match header field.
is to allow 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 method
(e.g. PUT) from inadvertently modifying an existing resource when (e.g. PUT) from inadvertently modifying an existing resource when
the client believes that the resource does not exist. the client believes that the resource does not exist.
As a special case, the value "*" matches any current entity of the As a special case, the value "*" matches any current entity of the
resource. 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
skipping to change at page 15, line 40 skipping to change at page 15, line 39
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 entity tags match.
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 5 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
skipping to change at page 16, line 25 skipping to change at page 16, line 24
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 request-header field "If-Unmodified-Since" is used with a method The "If-Unmodified-Since" request-header field is used to make a
to make it conditional. If the requested resource has not been request method conditional. If the requested resource has not been
modified since the time specified in this field, the server SHOULD modified since the time specified in this field, the server SHOULD
perform the requested operation as if the If-Unmodified-Since header perform the requested operation as if the If-Unmodified-Since header
were not present. were not 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).
If-Unmodified-Since = "If-Unmodified-Since" ":" OWS If-Unmodified-Since = "If-Unmodified-Since" ":" OWS
If-Unmodified-Since-v If-Unmodified-Since-v
skipping to change at page 17, line 7 skipping to change at page 17, line 7
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 6.6. Last-Modified
The entity-header field "Last-Modified" indicates the date and time The "Last-Modified" entity-header field indicates the date and time
at which the origin server believes the variant was last modified. at which the origin server believes the variant 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 The exact meaning of this header field depends on the implementation
skipping to change at page 17, line 46 skipping to change at page 17, line 46
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.
The Last-Modified entity-header field value is often used as a cache 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 validator. In simple terms, a cache entry is considered to be valid
if the entity has not been modified since the Last-Modified value. if the entity has not been modified since the Last-Modified value.
7. IANA Considerations 7. IANA Considerations
7.1. Message Header Registration 7.1. Status Code Registration
The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-status-codes> should be updated
with the registrations below:
+-------+---------------------+-------------+
| Value | Description | Reference |
+-------+---------------------+-------------+
| 304 | Not Modified | Section 3.1 |
| 412 | Precondition Failed | Section 3.2 |
+-------+---------------------+-------------+
7.2. Message Header Registration
The Message Header Registry located at <http://www.iana.org/ The Message Header Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> should be assignments/message-headers/message-header-index.html> should be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [RFC3864]):
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
| ETag | http | standard | Section 6.1 | | ETag | http | standard | Section 6.1 |
| If-Match | http | standard | Section 6.2 | | If-Match | http | standard | Section 6.2 |
skipping to change at page 18, line 33 skipping to change at page 18, 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-07 and Message Parsing", draft-ietf-httpbis-p1-messaging-08
(work in progress), July 2009. (work in progress), October 2009.
[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-07 (work Partial Responses", draft-ietf-httpbis-p5-range-08 (work
in progress), July 2009. in progress), October 2009.
[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-07 (work in 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in
progress), July 2009. progress), October 2009.
[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 20, line 10 skipping to change at page 20, line 10
A.1. Changes from RFC 2616 A.1. Changes from RFC 2616
Allow weak entity tags in all requests except range requests Allow weak entity tags in all requests except range requests
(Sections 4 and 6.4). (Sections 4 and 6.4).
Appendix B. Collected ABNF Appendix B. Collected ABNF
ETag = "ETag:" OWS ETag-v ETag = "ETag:" OWS ETag-v
ETag-v = entity-tag ETag-v = entity-tag
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
If-Match = "If-Match:" OWS If-Match-v If-Match = "If-Match:" OWS If-Match-v
If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v
If-Modified-Since-v = HTTP-date If-Modified-Since-v = HTTP-date
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 = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Unmodified-Since = "If-Unmodified-Since:" OWS If-Unmodified-Since = "If-Unmodified-Since:" OWS
skipping to change at page 22, line 33 skipping to change at page 22, line 33
o Add appendix containing collected and expanded ABNF, reorganize o Add appendix containing collected and expanded ABNF, reorganize
ABNF introduction. ABNF introduction.
C.8. Since draft-ietf-httpbis-p4-conditional-06 C.8. Since draft-ietf-httpbis-p4-conditional-06
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/153>: "case- o <http://tools.ietf.org/wg/httpbis/trac/ticket/153>: "case-
sensitivity of etag weakness indicator" sensitivity of etag weakness indicator"
C.9. Since draft-ietf-httpbis-p4-conditional-07
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
non-GET requests" (If-Match still was defined to require strong
matching)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes"
Index Index
3 3
304 Not Modified (status code) 6 304 Not Modified (status code) 6
4 4
412 Precondition Failed (status code) 6 412 Precondition Failed (status code) 6
E E
ETag header 11 ETag header 11
 End of changes. 27 change blocks. 
47 lines changed or deleted 70 lines changed or added

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