draft-ietf-httpbis-p4-conditional-08.txt   draft-ietf-httpbis-p4-conditional-09.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: April 29, 2010 J. Mogul Expires: September 9, 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
October 26, 2009 March 8, 2010
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-08 draft-ietf-httpbis-p4-conditional-09
Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 4 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
request header fields for indicating conditional requests and the
rules for constructing responses to those requests.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
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
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.10.
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.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
skipping to change at page 2, line 4 skipping to change at page 2, line 15
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Hypertext Transfer Protocol (HTTP) is an application-level described in the BSD License.
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 4 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
request header fields for indicating conditional requests and the
rules for constructing responses to those requests.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
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
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.9. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 48 skipping to change at page 3, line 48
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 C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22
C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 22
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 10, line 22 skipping to change at page 10, line 22
lead to serious problems. 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 legal, a strong entity tag MUST change whenever the
associated entity changes in any way. A weak entity tag SHOULD associated entity changes in any way. A weak entity tag SHOULD
change whenever the associated entity changes in a semantically change whenever the associated entity changes in a semantically
significant way. 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 entities, or reusing a specific weak value for two different entities, or reusing a specific weak
entity tag value for two semantically different entities. Cache entity tag value for two semantically different entities. Cache
entries might persist for arbitrarily long periods, regardless of entries might persist for arbitrarily long periods, regardless of
expiration times, so it might be inappropriate to expect that a expiration times, so it might be inappropriate to expect that a
cache will never again attempt to validate an entry using a cache will never again attempt to validate an entry using a
validator that it obtained at some point in the past. validator that it obtained at some point in the past.
HTTP/1.1 clients: HTTP/1.1 clients:
o If an entity tag has been provided by the origin server, MUST use o MUST use that entity tag in any cache-conditional request (using
that entity tag in any cache-conditional request (using If-Match If-Match or If-None-Match) if an entity tag has been provided by
or If-None-Match). the origin server.
o If only a Last-Modified value has been provided by the origin o SHOULD use the Last-Modified value in non-subrange cache-
server, SHOULD use that value in non-subrange cache-conditional conditional requests (using If-Modified-Since) if only a Last-
requests (using If-Modified-Since). Modified value has been provided by the origin server.
o If only a Last-Modified value has been provided by an HTTP/1.0 o MAY use the Last-Modified value in subrange cache-conditional
origin server, MAY use that value in subrange cache-conditional requests (using If-Unmodified-Since) if only a Last-Modified value
requests (using If-Unmodified-Since:). The user agent SHOULD has been provided by an HTTP/1.0 origin server. The user agent
provide a way to disable this, in case of difficulty. SHOULD provide a way to disable this, in case of difficulty.
o If both an entity tag and a Last-Modified value have been provided o SHOULD use both validators in cache-conditional requests if both
by the origin server, SHOULD use both validators in cache- an entity tag and a Last-Modified value have been provided by the
conditional requests. This allows both HTTP/1.0 and HTTP/1.1 origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
caches to respond appropriately. respond appropriately.
An HTTP/1.1 origin server, upon receiving a conditional request that An HTTP/1.1 origin server, upon receiving a conditional request that
includes both a Last-Modified date (e.g., in an If-Modified-Since or includes both a Last-Modified date (e.g., in an If-Modified-Since or
If-Unmodified-Since header field) and one or more entity tags (e.g., If-Unmodified-Since header field) and one or more entity tags (e.g.,
in an If-Match, If-None-Match, or If-Range header field) as cache in an If-Match, If-None-Match, or If-Range header field) as cache
validators, MUST NOT return a response status of 304 (Not Modified) validators, MUST NOT return a response status of 304 (Not Modified)
unless doing so is consistent with all of the conditional header unless doing so is consistent with all of the conditional header
fields in the request. fields in the request.
An HTTP/1.1 caching proxy, upon receiving a conditional request that An HTTP/1.1 caching proxy, upon receiving a conditional request that
skipping to change at page 15, line 17 skipping to change at page 15, line 17
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" request-header field is used to make a request
method 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. 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 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
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
skipping to change at page 18, line 46 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-08 and Message Parsing", draft-ietf-httpbis-p1-messaging-09
(work in progress), October 2009. (work in progress), March 2010.
[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-08 (work Partial Responses", draft-ietf-httpbis-p5-range-09 (work
in progress), October 2009. in progress), March 2010.
[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-08 (work in 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
progress), October 2009. progress), March 2010.
[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 22, line 44 skipping to change at page 22, line 44
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
non-GET requests" (If-Match still was defined to require strong non-GET requests" (If-Match still was defined to require strong
matching) matching)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes" registrations for optional status codes"
C.10. Since draft-ietf-httpbis-p4-conditional-08
No significant changes.
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. 21 change blocks. 
63 lines changed or deleted 75 lines changed or added

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