draft-ietf-httpbis-p4-conditional-11.txt   draft-ietf-httpbis-p4-conditional-12.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 Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: February 5, 2011 J. Mogul Expires: April 28, 2011 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
August 4, 2010 October 25, 2010
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-11 draft-ietf-httpbis-p4-conditional-12
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 4 of the information initiative since 1990. This document is Part 4 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
request header fields for indicating conditional requests and the request header fields for indicating conditional requests and the
rules for constructing responses to those requests. rules for constructing responses to those requests.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.12. The changes in this draft are summarized in Appendix C.13.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 6
2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Example: Entity-tags varying on Content-Negotiated 2.1. Example: Entity-tags varying on Content-Negotiated
Resources . . . . . . . . . . . . . . . . . . . . . . . . 6 Resources . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 8
3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 8
3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 7 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8
4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 9
5. Rules for When to Use Entity-tags and Last-Modified Dates . . 10 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 11
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 13
6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15
6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 17
6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18
6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 20
7.2. Header Field Registration . . . . . . . . . . . . . . . . 19 7.2. Header Field Registration . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 21 publication) . . . . . . . . . . . . . . . . . . . . 22
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23
C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22 C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23
C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22 C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23
C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22 C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23
C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24
C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23 C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24
C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23 C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24
C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23 C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24
C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23 C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24
C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23 C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24
C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document defines HTTP/1.1 response metadata for indicating This document defines HTTP/1.1 response metadata for indicating
potential changes to payload content, including modification time potential changes to payload content, including modification time
stamps and opaque entity-tags, and the HTTP conditional request stamps and opaque entity-tags, and the HTTP conditional request
mechanisms that allow preconditions to be placed on a request method. mechanisms that allow preconditions to be placed on a request method.
Conditional GET requests allow for efficient cache updates. Other Conditional GET requests allow for efficient cache updates. Other
conditional request methods are used to protect against overwriting conditional request methods are used to protect against overwriting
or misunderstanding the state of a resource that has been changed or misunderstanding the state of a resource that has been changed
unbeknownst to the requesting client. unbeknownst to the requesting client.
This document is currently disorganized in order to minimize the This document is currently disorganized in order to minimize the
changes between drafts and enable reviewers to see the smaller errata changes between drafts and enable reviewers to see the smaller errata
changes. The next draft will reorganize the sections to better changes. A future draft will reorganize the sections to better
reflect the content. In particular, the sections on resource reflect the content. In particular, the sections on resource
metadata will be discussed first and then followed by each metadata will be discussed first and then followed by each
conditional request-header, concluding with a definition of conditional request-header field, concluding with a definition of
precedence and the expectation of ordering strong validator checks precedence and the expectation of ordering strong validator checks
before weak validator checks. It is likely that more content from before weak validator checks. It is likely that more content from
[Part6] will migrate to this part, where appropriate. The current [Part6] will migrate to this part, where appropriate. The current
mess reflects how widely dispersed these topics and associated mess reflects how widely dispersed these topics and associated
requirements had become in [RFC2616]. requirements had become in [RFC2616].
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 10, line 5 skipping to change at page 11, line 5
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 representation and, current validator for the representation and,
o That origin server reliably knows that the associated o That origin server reliably knows that the associated
representation did not change twice during the second covered by representation did not change twice during the second covered by
the presented validator. the presented 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 field, because the client has
cache entry for the associated representation, and a cache entry for the associated representation, and
o That cache entry includes a Date value, which gives the time when o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the o The presented Last-Modified time is at least 60 seconds before the
Date value. Date value.
or or
o The validator is being compared by an intermediate cache to the o The validator is being compared by an intermediate cache to the
skipping to change at page 11, line 17 skipping to change at page 12, line 17
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.
o MAY send a weak entity-tag instead of a strong entity-tag, if o MAY send a weak entity-tag instead of a strong entity-tag, if
performance considerations support the use of weak entity-tags, or performance considerations support the use of weak entity-tags, or
if it is unfeasible to send a strong entity-tag. if it is unfeasible to send a strong entity-tag.
o SHOULD send a Last-Modified value if it is feasible to send one, o SHOULD send a Last-Modified value if it is feasible to send one,
unless the risk of a breakdown in semantic transparency that could unless the risk of a breakdown in semantic transparency that could
result from using this date in an If-Modified-Since header would result from using this date in an If-Modified-Since header field
lead to serious problems. would lead to serious problems.
In other words, the preferred behavior for an HTTP/1.1 origin server In other words, the preferred behavior for an HTTP/1.1 origin server
is to send both a strong entity-tag and a Last-Modified value. is to send both a strong entity-tag and a Last-Modified value.
In order to be legal, a strong entity-tag MUST change whenever the In order to be legal, a strong entity-tag MUST change whenever the
associated representation changes in any way. A weak entity-tag associated representation changes in any way. A weak entity-tag
SHOULD change whenever the associated representation changes in a SHOULD change whenever the associated representation changes in a
semantically significant way. semantically significant way.
Note: In order to provide semantically transparent caching, an Note: In order to provide semantically transparent caching, an
skipping to change at page 13, line 23 skipping to change at page 14, line 23
more reliable validation than modification dates in situations where more reliable validation than modification dates in situations where
it is inconvenient to store modification dates, where the one-second it is inconvenient to store modification dates, where the one-second
resolution of HTTP date values is not sufficient, or where the origin resolution of HTTP date values is not sufficient, or where the origin
server wishes to avoid certain paradoxes that might arise from the server wishes to avoid certain paradoxes that might arise from the
use of modification dates. use of modification dates.
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 header fields
(except Last-Modified, for compatibility with HTTP/1.0) are never (except Last-Modified, for compatibility with HTTP/1.0) are never
used for purposes of validating a cache entry. used for purposes of validating a cache entry.
6.2. If-Match 6.2. If-Match
The "If-Match" request-header field is used to make a request method The "If-Match" request-header field is used to make a request method
conditional. A client that has one or more representations conditional. A client that has one or more representations
previously obtained from the resource can verify that one of those previously obtained from the resource can verify that one of those
representations is current by including a list of their associated representations is current by including a list of their associated
entity-tags in the If-Match header field. entity-tags in the If-Match header field.
skipping to change at page 13, line 46 skipping to change at page 14, line 46
amount of transaction overhead. It is also used when updating amount of transaction overhead. It is also used when updating
resources, to prevent inadvertent modification of the wrong version resources, to prevent inadvertent modification of the wrong version
of a resource. As a special case, the value "*" matches any current of a resource. As a special case, the value "*" matches any current
representation of the resource. representation of the resource.
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 representation If any of the entity-tags match the entity-tag of the representation
that would have been returned in the response to a similar GET that would have been returned in the response to a similar GET
request (without the If-Match header) on that resource, or if "*" is request (without the If-Match header field) on that resource, or if
given and any current representation exists for that resource, then "*" is given and any current representation exists for that resource,
the server MAY perform the requested method as if the If-Match header then the server MAY perform the requested method as if the If-Match
field did not exist. header field did not exist.
If none of the entity-tags match, or if "*" is given and no current If none of the entity-tags match, or if "*" is given and no current
representation exists, the server MUST NOT perform the requested representation exists, the server MUST NOT perform the requested
method, and MUST return a 412 (Precondition Failed) response. This method, and MUST return a 412 (Precondition Failed) response. This
behavior is most useful when the client wants to prevent an updating behavior is most useful when the client wants to prevent an updating
method, such as PUT, from modifying a resource that has changed since method, such as PUT, from modifying a resource that has changed since
the client last retrieved it. the client last retrieved it.
If the request would, without the If-Match header field, result in If the request would, without the If-Match header field, result in
anything other than a 2xx or 412 status code, then the If-Match anything other than a 2xx or 412 status code, then the If-Match
header MUST be ignored. header field MUST be ignored.
The meaning of "If-Match: *" is that the method SHOULD be performed The meaning of "If-Match: *" is that the 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 3.5 of [Part6]) possibly using the Vary mechanism, see Section 3.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 representation corresponding to the If-Match value (a applied if the representation corresponding to the If-Match value (a
skipping to change at page 15, line 5 skipping to change at page 16, line 5
the method; instead, respond as detailed below. the method; instead, respond as detailed below.
If-Modified-Since = "If-Modified-Since" ":" OWS If-Modified-Since = "If-Modified-Since" ":" OWS
If-Modified-Since-v If-Modified-Since-v
If-Modified-Since-v = HTTP-date If-Modified-Since-v = HTTP-date
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A GET method with an If-Modified-Since header and no Range header A GET method with an If-Modified-Since header field and no Range
requests that the representation be transferred only if it has been header field requests that the representation be transferred only if
modified since the date given by the If-Modified-Since header. The it has been modified since the date given by the If-Modified-Since
algorithm for determining this includes the following cases: header field. The algorithm for determining this includes the
following cases:
1. If the request would normally result in anything other than a 200 1. If the request would normally result in anything other than a 200
(OK) status code, or if the passed If-Modified-Since date is (OK) status code, or if the passed If-Modified-Since date is
invalid, the response is exactly the same as for a normal GET. A invalid, the response is exactly the same as for a normal GET. A
date which is later than the server's current time is invalid. date which is later than the server's current time is invalid.
2. If the representation has been modified since the If-Modified- 2. If the representation has been modified since the If-Modified-
Since date, the response is exactly the same as for a normal GET. Since date, the response is exactly the same as for a normal GET.
3. If the representation has not been modified since a valid If- 3. If the representation has not been modified since a valid If-
skipping to change at page 15, line 40 skipping to change at page 16, line 41
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-
Modified header field whenever possible. Modified header field whenever possible.
Note: If a client uses an arbitrary date in the If-Modified-Since Note: If a client uses an arbitrary date in the If-Modified-Since
header instead of a date taken from the Last-Modified header for header field instead of a date taken from the Last-Modified header
the same request, the client needs to be aware that this date is field for the same request, the client needs to be aware that this
interpreted in the server's understanding of time. Unsynchronized date is interpreted in the server's understanding of time.
clocks and rounding problems, due to the different encodings of Unsynchronized clocks and rounding problems, due to the different
time between the client and server, are concerns. This includes encodings of time between the client and server, are concerns.
the possibility of race conditions if the document has changed This includes the possibility of race conditions if the document
between the time it was first requested and the If-Modified-Since has changed between the time it was first requested and the If-
date of a subsequent request, and the possibility of clock-skew- Modified-Since date of a subsequent request, and the possibility
related problems if the If-Modified-Since date is derived from the of clock-skew-related problems if the If-Modified-Since date is
client's clock without correction to the server's clock. derived from the client's clock without correction to the server's
Corrections for different time bases between client and server are clock. Corrections for different time bases between client and
at best approximate due to network latency. server are at best approximate due to network latency.
The result of a request having both an If-Modified-Since header field The result of a request having both an If-Modified-Since header field
and either an If-Match or an If-Unmodified-Since header fields is and either an If-Match or an If-Unmodified-Since header fields is
undefined by this specification. undefined by this specification.
6.4. If-None-Match 6.4. If-None-Match
The "If-None-Match" request-header field is used to make a request The "If-None-Match" request-header field is used to make a request
method conditional. A client that has one or more representations method conditional. A client that has one or more representations
previously obtained from the resource can verify that none of those previously obtained from the resource can verify that none of those
skipping to change at page 16, line 30 skipping to change at page 17, line 30
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 representation As a special case, the value "*" matches any current representation
of the resource. of the resource.
If-None-Match = "If-None-Match" ":" OWS If-None-Match-v If-None-Match = "If-None-Match" ":" OWS If-None-Match-v
If-None-Match-v = "*" / 1#entity-tag If-None-Match-v = "*" / 1#entity-tag
If any of the entity-tags match the entity-tag of the representation If any of the entity-tags match the entity-tag of the representation
that would have been returned in the response to a similar GET that would have been returned in the response to a similar GET
request (without the If-None-Match header) on that resource, or if request (without the If-None-Match header field) on that resource, or
"*" is given and any current representation exists for that resource, if "*" is given and any current representation exists for that
then the server MUST NOT perform the requested method, unless resource, then the server MUST NOT perform the requested method,
required to do so because the resource's modification date fails to unless required to do so because the resource's modification date
match that supplied in an If-Modified-Since header field in the fails to match that supplied in an If-Modified-Since header field in
request. Instead, if the request method was GET or HEAD, the server the request. Instead, if the request method was GET or HEAD, the
SHOULD respond with a 304 (Not Modified) response, including the server SHOULD respond with a 304 (Not Modified) response, including
cache-related header fields (particularly ETag) of one of the the cache-related header fields (particularly ETag) of one of the
representations that matched. For all other request methods, the representations that matched. For all other request methods, the
server MUST respond with a 412 (Precondition Failed) status code. server MUST respond with a 412 (Precondition Failed) status code.
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 code, then the If-None- in anything other than a 2xx or 304 status code, then the If-None-
Match header MUST be ignored. (See Section 5 for a discussion of Match header field MUST be ignored. (See Section 5 for a discussion
server behavior when both If-Modified-Since and If-None-Match appear of server behavior when both If-Modified-Since and If-None-Match
in the same request.) appear in the 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 3.5 of a cache, possibly using the Vary mechanism, see Section 3.5 of
[Part6]) exists, and SHOULD be performed if the representation does [Part6]) exists, and SHOULD be performed if the representation does
not exist. This feature is intended to be useful in preventing races not exist. This feature is intended to be useful in preventing races
between PUT operations. between PUT operations.
Examples: Examples:
If-None-Match: "xyzzy" If-None-Match: "xyzzy"
skipping to change at page 17, line 30 skipping to change at page 18, line 30
either an If-Match or an If-Unmodified-Since header fields is either an If-Match or an If-Unmodified-Since header fields is
undefined by this specification. undefined by this specification.
6.5. If-Unmodified-Since 6.5. If-Unmodified-Since
The "If-Unmodified-Since" request-header field is used to make a The "If-Unmodified-Since" request-header field is used to make a
request method conditional. If the representation that would have request method conditional. If the representation that would have
been transferred in a 200 response to a GET request on the same been transferred in a 200 response to a GET request on the same
resource has not been modified since the time specified in this resource has not been modified since the time specified in this
field, the server SHOULD perform the requested operation as if the field, the server SHOULD perform the requested operation as if the
If-Unmodified-Since header were not present. If-Unmodified-Since header field were not present.
If the representation has been modified since the specified time, the If the representation has been modified since the specified time, the
server MUST NOT perform the requested operation, and MUST return a server MUST NOT perform the requested operation, and MUST return a
412 (Precondition Failed). 412 (Precondition Failed).
If-Unmodified-Since = "If-Unmodified-Since" ":" OWS If-Unmodified-Since = "If-Unmodified-Since" ":" OWS
If-Unmodified-Since-v If-Unmodified-Since-v
If-Unmodified-Since-v = HTTP-date If-Unmodified-Since-v = HTTP-date
An example of the field is: An example of the field is:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If the request normally (i.e., without the If-Unmodified-Since If the request normally (i.e., without the If-Unmodified-Since header
header) would result in anything other than a 2xx or 412 status code, field) would result in anything other than a 2xx or 412 status code,
the If-Unmodified-Since header SHOULD be ignored. the If-Unmodified-Since header field SHOULD be ignored.
If the specified date is invalid, the header is ignored. If the specified date is invalid, the header field 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 "Last-Modified" header field indicates the date and time at which The "Last-Modified" header field indicates the date and time at which
the origin server believes the representation was last modified. the origin server believes the representation was last modified.
skipping to change at page 19, line 51 skipping to change at page 20, line 51
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-11 and Message Parsing", draft-ietf-httpbis-p1-messaging-12
(work in progress), August 2010. (work in progress), October 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-11 and Content Negotiation", draft-ietf-httpbis-p3-payload-12
(work in progress), August 2010. (work in progress), October 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-11 (work Partial Responses", draft-ietf-httpbis-p5-range-12 (work
in progress), August 2010. in progress), October 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-11 (work in 6: Caching", draft-ietf-httpbis-p6-cache-12 (work in
progress), August 2010. progress), October 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 21, line 48 skipping to change at page 22, line 48
; ETag defined but not used ; ETag defined but not used
; If-Match defined but not used ; If-Match defined but not used
; If-Modified-Since defined but not used ; If-Modified-Since defined but not used
; If-None-Match defined but not used ; If-None-Match defined but not used
; If-Unmodified-Since defined but not used ; If-Unmodified-Since defined but not used
; Last-Modified defined but not used ; Last-Modified defined but not used
Appendix C. Change Log (to be removed by RFC Editor before publication) Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since RFC2616 C.1. Since RFC 2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
C.2. Since draft-ietf-httpbis-p4-conditional-00 C.2. Since draft-ietf-httpbis-p4-conditional-00
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
Informative references" Informative references"
skipping to change at page 22, line 31 skipping to change at page 23, line 31
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
C.4. Since draft-ietf-httpbis-p4-conditional-02 C.4. Since draft-ietf-httpbis-p4-conditional-02
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" non-GET requests"
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Field Registration
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header registrations for headers o Reference RFC 3984, and update header field registrations for
defined in this document. header fields defined in this document.
C.5. Since draft-ietf-httpbis-p4-conditional-03 C.5. Since draft-ietf-httpbis-p4-conditional-03
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for
ETag matching" ETag matching"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity
value' undefined" value' undefined"
skipping to change at page 23, line 16 skipping to change at page 24, line 16
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Use "/" instead of "|" for alternatives. o Use "/" instead of "|" for alternatives.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS"). whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header o Rewrite ABNFs to spell out whitespace rules, factor out header
value format definitions. field value format definitions.
C.7. Since draft-ietf-httpbis-p4-conditional-05 C.7. Since draft-ietf-httpbis-p4-conditional-05
Final work on ABNF conversion Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
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
skipping to change at page 24, line 18 skipping to change at page 25, line 18
o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
'Requested Variant'" 'Requested Variant'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
entity / representation / variant terminology" entity / representation / variant terminology"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections" removing the 'changes from 2068' sections"
C.13. Since draft-ietf-httpbis-p4-conditional-11
None.
Index Index
3 3
304 Not Modified (status code) 7 304 Not Modified (status code) 8
4 4
412 Precondition Failed (status code) 7 412 Precondition Failed (status code) 8
E E
ETag header 12 ETag header 13
G G
Grammar Grammar
entity-tag 5 entity-tag 6
ETag 12 ETag 13
ETag-v 12 ETag-v 13
If-Match 13 If-Match 14
If-Match-v 13 If-Match-v 14
If-Modified-Since 14 If-Modified-Since 15
If-Modified-Since-v 14 If-Modified-Since-v 15
If-None-Match 16 If-None-Match 17
If-None-Match-v 16 If-None-Match-v 17
If-Unmodified-Since 17 If-Unmodified-Since 18
If-Unmodified-Since-v 17 If-Unmodified-Since-v 18
Last-Modified 18 Last-Modified 19
Last-Modified-v 18 Last-Modified-v 19
opaque-tag 5 opaque-tag 6
weak 5 weak 6
H H
Headers Headers
ETag 12 ETag 13
If-Match 13 If-Match 14
If-Modified-Since 14 If-Modified-Since 15
If-None-Match 16 If-None-Match 17
If-Unmodified-Since 17 If-Unmodified-Since 18
Last-Modified 18 Last-Modified 19
I I
If-Match header 13 If-Match header 14
If-Modified-Since header 14 If-Modified-Since header 15
If-None-Match header 16 If-None-Match header 17
If-Unmodified-Since header 17 If-Unmodified-Since header 18
L L
Last-Modified header 18 Last-Modified header 19
S S
Status Codes Status Codes
304 Not Modified 7 304 Not Modified 8
412 Precondition Failed 7 412 Precondition Failed 8
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
 End of changes. 40 change blocks. 
136 lines changed or deleted 143 lines changed or added

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