draft-ietf-httpbis-p4-conditional-05.txt   draft-ietf-httpbis-p4-conditional-06.txt 
Network 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: May 20, 2009 J. Mogul Expires: September 10, 2009 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
November 16, 2008 March 9, 2009
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-05 draft-ietf-httpbis-p4-conditional-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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 1, line 42 skipping to change at page 2, line 4
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 May 20, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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/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 B.6. The changes in this draft are summarized in Appendix C.7.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 1.2.2. ABNF Rules defined in other Parts of the
4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 Specification . . . . . . . . . . . . . . . . . . . . 5
4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6
6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 6
7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6
7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7
7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9
7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11
7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Message Header Registration . . . . . . . . . . . . . . . 17 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Message Header Registration . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Compatibility with Previous Versions . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Compatibility with Previous Versions . . . . . . . . 19
A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
publication) . . . . . . . . . . . . . . . . . . . . 19 Appendix C. Change Log (to be removed by RFC Editor before
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 publication) . . . . . . . . . . . . . . . . . . . . 20
B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19 C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21
B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19 C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21
B.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 20 C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21
B.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 20 C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
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
conditional request methods are used to protect against overwriting conditional request methods are used to protect against overwriting
or misunderstanding the state of a resource that has been changed or misunderstanding the state of a resource that has been changed
skipping to change at page 4, line 43 skipping to change at page 4, line 43
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the MUST or
REQUIRED level and all the SHOULD level requirements for its REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant."
2. Notational Conventions and Generic Grammar 1.2. Syntax Notation
This specification uses the ABNF syntax defined in Section 2.1 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] and the core rules defined in Section 2.2 of [Part1]: [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix B shows the collected ABNF, with the list rule
expanded.
quoted-string = <quoted-string, defined in [Part1], Section 2.2> The following core rules are included by reference, as defined in
OWS = <OWS, defined in [Part1], Section 2.2> [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible USASCII character),
and WSP (whitespace).
1.2.1. Core Rules
The core rules below are defined in Section 1.2.2 of [Part1]:
quoted-string = <quoted-string, 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
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.3.1> HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1>
3. 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 7.1), If-Match (Section 7.2), If-None-Match (Section 7.4), (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4),
and If-Range (Section 6.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 5. 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.
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = "W/" weak = "W/"
opaque-tag = quoted-string opaque-tag = quoted-string
A "strong entity tag" MAY be shared by two entities of a resource A "strong entity tag" MAY be shared by two entities of a resource
only if they are equivalent by octet equality. only if they are equivalent by octet equality.
A "weak entity tag," indicated by the "W/" prefix, MAY be shared by A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
skipping to change at page 5, line 36 skipping to change at page 6, line 5
could be substituted for each other with no significant change in could be substituted for each other with no significant change in
semantics. A weak entity tag can only be used for weak comparison. semantics. A weak entity tag can only be used for weak comparison.
An entity tag MUST be unique across all versions of all entities An entity tag MUST be unique across all versions of all entities
associated with a particular resource. A given entity tag value MAY associated with a particular resource. A given entity tag value MAY
be used for entities obtained by requests on different URIs. The use be used for entities obtained by requests on different URIs. The use
of the same entity tag value in conjunction with entities obtained by of the same entity tag value in conjunction with entities obtained by
requests on different URIs does not imply the equivalence of those requests on different URIs does not imply the equivalence of those
entities. entities.
4. Status Code Definitions 3. Status Code Definitions
4.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 8.3.1 of [Part1].
skipping to change at page 6, line 15 skipping to change at page 6, line 31
(as already specified by Section 8.3 of [Part1], caches will (as already specified by Section 8.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 5), If the conditional GET used a strong cache validator (see Section 4),
the response SHOULD NOT include other entity-headers. Otherwise the response SHOULD NOT include other entity-headers. Otherwise
(i.e., the conditional GET used a weak validator), the response MUST (i.e., the conditional GET used a weak validator), the response MUST
NOT include other entity-headers; this prevents inconsistencies NOT include other entity-headers; this prevents inconsistencies
between cached entity-bodies and updated headers. between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the cache MUST disregard the response and repeat the request without the
conditional. conditional.
If a cache uses a received 304 response to update a cache entry, the If a cache uses a received 304 response to update a cache entry, the
cache MUST update the entry to reflect any new field values given in cache MUST update the entry to reflect any new field values given in
the response. the response.
4.2. 412 Precondition Failed 3.2. 412 Precondition Failed
The precondition given in one or more of the request-header fields The precondition given in one or more of the request-header fields
evaluated to false when it was tested on the server. This response evaluated to false when it was tested on the server. This response
code allows the client to place preconditions on the current resource code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested metainformation (header field data) and thus prevent the requested
method from being applied to a resource other than the one intended. method from being applied to a resource other than the one intended.
5. Weak and Strong Validators 4. Weak and Strong Validators
Since both origin servers and caches will compare two validators to Since both origin servers and caches will compare two validators to
decide if they represent the same or different entities, one normally decide if they represent the same or different entities, one normally
would expect that if the entity (the entity-body or any entity- would expect that if the entity (the entity-body or any entity-
headers) changes in any way, then the associated validator would headers) changes in any way, then the associated validator would
change as well. If this is true, then we call this validator a change as well. If this is true, then we call this validator a
"strong validator." "strong validator."
However, there might be cases when a server prefers to change the However, there might be cases when a server prefers to change the
validator only on semantically significant changes, and not when validator only on semantically significant changes, and not when
skipping to change at page 8, line 15 skipping to change at page 8, line 29
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
| 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 |
| "1" | "1" | match | match | | "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
An entity tag is strong unless it is explicitly tagged as weak. An entity tag is strong unless it is explicitly tagged as weak.
Section 3 gives the syntax for entity tags. Section 2 gives the syntax for entity tags.
A Last-Modified time, when used as a validator in a request, is A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong, implicitly weak unless it is possible to deduce that it is strong,
using the following rules: using the following rules:
o The validator is being compared by an origin server to the actual o The validator is being compared by an origin server to the actual
current validator for the entity and, current validator for the entity and,
o That origin server reliably knows that the associated entity did o That origin server reliably knows that the associated entity did
not change twice during the second covered by the presented not change twice during the second covered by the presented
skipping to change at page 9, line 25 skipping to change at page 9, line 39
described here. described here.
A cache or origin server receiving a conditional range request A cache or origin server receiving a conditional range request
([Part5]) MUST use the strong comparison function to evaluate the ([Part5]) MUST use the strong comparison function to evaluate the
condition. condition.
These rules allow HTTP/1.1 caches and clients to safely perform sub- These rules allow HTTP/1.1 caches and clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0 range retrievals on values that have been obtained from HTTP/1.0
servers. servers.
6. Rules for When to Use Entity Tags and Last-Modified Dates 5. Rules for When to Use Entity Tags and Last-Modified Dates
We adopt a set of rules and recommendations for origin servers, We adopt a set of rules and recommendations for origin servers,
clients, and caches regarding when various validator types ought to clients, and caches regarding when various validator types ought to
be used, and for what purposes. be used, and for what purposes.
HTTP/1.1 origin servers: HTTP/1.1 origin servers:
o SHOULD send an entity tag validator unless it is not feasible to o SHOULD send an entity tag validator unless it is not feasible to
generate one. generate one.
skipping to change at page 11, line 16 skipping to change at page 11, line 28
conservative assumptions about the validators they receive. conservative assumptions about the validators they receive.
HTTP/1.0 clients and caches will ignore entity tags. Generally, HTTP/1.0 clients and caches will ignore entity tags. Generally,
last-modified values received or used by these systems will last-modified values received or used by these systems will
support transparent and efficient caching, and so HTTP/1.1 origin support transparent and efficient caching, and so HTTP/1.1 origin
servers should provide Last-Modified values. In those rare cases servers should provide Last-Modified values. In those rare cases
where the use of a Last-Modified value as a validator by an where the use of a Last-Modified value as a validator by an
HTTP/1.0 system could result in a serious problem, then HTTP/1.1 HTTP/1.0 system could result in a serious problem, then HTTP/1.1
origin servers should not provide one. origin servers should not provide one.
7. Header Field Definitions 6. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to conditional requests. fields related to conditional requests.
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.
7.1. ETag 6.1. ETag
The response-header field "ETag" provides the current value of the The response-header field "ETag" provides the current value of the
entity tag (see Section 3) for the requested variant. The headers entity tag (see Section 2) for the requested variant. The headers
used with entity tags are described in Sections 7.2 and 7.4 of this used with entity tags are described in Sections 6.2 and 6.4 of this
document, and in Section 6.3 of [Part5]. The entity tag MAY be used document, and in Section 5.3 of [Part5]. The entity tag MAY be used
for comparison with other entities from the same resource (see for comparison with other entities from the same resource (see
Section 5). 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: ""
The ETag response-header field value, an entity tag, provides for an The ETag response-header field value, an entity tag, provides for an
"opaque" cache validator. This might allow more reliable validation "opaque" cache validator. This might allow more reliable validation
in situations where it is inconvenient to store modification dates, in situations where it is inconvenient to store modification dates,
where the one-second resolution of HTTP date values is not where the one-second resolution of HTTP date values is not
skipping to change at page 12, line 10 skipping to change at page 12, line 25
paradoxes that might arise from the use of modification dates. paradoxes that might arise from the 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 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.
7.2. If-Match 6.2. If-Match
The request-header field "If-Match" is used with a method to make it The request-header field "If-Match" is used with a method to make it
conditional. A client that has one or more entities previously conditional. A client that has one or more entities previously
obtained from the resource can verify that one of those entities is obtained from the resource can verify that one of those entities is
current by including a list of their associated entity tags in the current by including a list of their associated entity tags in the
If-Match header field. Entity tags are defined in Section 3. The If-Match header field. Entity tags are defined in Section 2. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. It is information with a minimum amount of transaction overhead. It is
also used, on updating requests, to prevent inadvertent modification also used, on updating requests, to prevent inadvertent modification
of the wrong version of a resource. As a special case, the value "*" of the wrong version of a resource. As a special case, the value "*"
matches any current entity of the resource. matches any current entity of the resource.
If-Match = "If-Match" ":" 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 5) to A server MUST use the strong comparison function (see Section 4) to
compare the entity tags in If-Match. compare the entity tags in If-Match.
If none of the entity tags match, or if "*" is given and no current If none of the entity tags match, or if "*" is given and no current
entity exists, the server MUST NOT perform the requested method, and entity exists, the server MUST NOT perform the requested method, and
MUST return a 412 (Precondition Failed) response. This behavior is MUST return a 412 (Precondition Failed) response. This behavior is
most useful when the client wants to prevent an updating method, such most useful when the client wants to prevent an updating method, such
as PUT, from modifying a resource that has changed since the client as PUT, from modifying a resource that has changed since the client
last retrieved it. last retrieved it.
If the request would, without the If-Match header field, result in If the request would, without the If-Match header field, result in
anything other than a 2xx or 412 status, then the If-Match header anything other than a 2xx or 412 status, then the If-Match header
MUST be ignored. MUST be ignored.
The meaning of "If-Match: *" is that the method SHOULD be performed The meaning of "If-Match: *" is that the method SHOULD be performed
if the representation selected by the origin server (or by a cache, if the representation selected by the origin server (or by a cache,
possibly using the Vary mechanism, see Section 16.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 entity corresponding to the If-Match value (a single applied if the entity corresponding to the If-Match value (a single
entity tag) is no longer a representation of that resource. This entity tag) is no longer a representation of that resource. This
allows the user to indicate that they do not wish the request to be allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. successful if the resource has been changed without their knowledge.
Examples: Examples:
If-Match: "xyzzy" If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: * If-Match: *
The result of a request having both an If-Match header field and The result of a request having both an If-Match header field and
either an If-None-Match or an If-Modified-Since header fields is either an If-None-Match or an If-Modified-Since header fields is
undefined by this specification. undefined by this specification.
7.3. If-Modified-Since 6.3. If-Modified-Since
The request-header field "If-Modified-Since" is used with a method to The request-header field "If-Modified-Since" is used with a method to
make it conditional: if the requested variant has not been modified make it conditional: if the requested variant has not been modified
since the time specified in this field, an entity will not be since the time specified in this field, an entity will not be
returned from the server; instead, a 304 (Not Modified) response will returned from the server; instead, a 304 (Not Modified) response will
be returned without any message-body. be returned without any message-body.
If-Modified-Since = "If-Modified-Since" ":" 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
skipping to change at page 14, line 9 skipping to change at page 14, line 25
date, the response is exactly the same as for a normal GET. date, the response is exactly the same as for a normal GET.
3. If the variant has not been modified since a valid If-Modified- 3. If the variant has not been modified since a valid If-Modified-
Since date, the server SHOULD return a 304 (Not Modified) Since date, the server SHOULD return a 304 (Not Modified)
response. response.
The purpose of this feature is to allow efficient updates of cached The purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. information with a minimum amount of transaction overhead.
Note: The Range request-header field modifies the meaning of If- Note: The Range request-header field modifies the meaning of If-
Modified-Since; see Section 6.4 of [Part5] for full details. Modified-Since; see Section 5.4 of [Part5] for full details.
Note: If-Modified-Since times are interpreted by the server, whose Note: If-Modified-Since times are interpreted by the server, whose
clock might not be synchronized with the client. clock might not be synchronized with the client.
Note: When handling an If-Modified-Since header field, some Note: When handling an If-Modified-Since header field, some
servers will use an exact date comparison function, rather than a servers will use an exact date comparison function, rather than a
less-than function, for deciding whether to send a 304 (Not less-than function, for deciding whether to send a 304 (Not
Modified) response. To get best results when sending an If- Modified) response. To get best results when sending an If-
Modified-Since header field for cache validation, clients are Modified-Since header field for cache validation, clients are
advised to use the exact date string received in a previous Last- advised to use the exact date string received in a previous Last-
skipping to change at page 14, line 41 skipping to change at page 15, line 9
possibility of clock-skew-related problems if the If-Modified- possibility of clock-skew-related problems if the If-Modified-
Since date is derived from the client's clock without correction Since date is derived from the client's clock without correction
to the server's clock. Corrections for different time bases to the server's clock. Corrections for different time bases
between client and server are at best approximate due to network between client and server are at best approximate due to network
latency. latency.
The result of a request having both an If-Modified-Since header field The result of a request having both an If-Modified-Since header field
and either an If-Match or an If-Unmodified-Since header fields is and either an If-Match or an If-Unmodified-Since header fields is
undefined by this specification. undefined by this specification.
7.4. If-None-Match 6.4. If-None-Match
The request-header field "If-None-Match" is used with a method to The request-header field "If-None-Match" is used with a method to
make it conditional. A client that has one or more entities make it 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. The purpose of this feature
is to allow efficient updates of cached information with a minimum is to allow 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.
skipping to change at page 15, line 24 skipping to change at page 15, line 40
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 5 for rules on how to determine if two entity tags match. 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 6 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
same request.) same request.)
The meaning of "If-None-Match: *" is that the method MUST NOT be The meaning of "If-None-Match: *" is that the method MUST NOT be
performed if the representation selected by the origin server (or by performed if the representation selected by the origin server (or by
a cache, possibly using the Vary mechanism, see Section 16.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"
If-None-Match: W/"xyzzy" If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
skipping to change at page 16, line 4 skipping to change at page 16, line 18
not exist. This feature is intended to be useful in preventing races not exist. This feature is intended to be useful in preventing races
between PUT operations. between PUT operations.
Examples: Examples:
If-None-Match: "xyzzy" If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy" If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: * If-None-Match: *
The result of a request having both an If-None-Match header field and The result of a request having both an If-None-Match header field and
either an If-Match or an If-Unmodified-Since header fields is either an If-Match or an If-Unmodified-Since header fields is
undefined by this specification. undefined by this specification.
7.5. If-Unmodified-Since 6.5. If-Unmodified-Since
The request-header field "If-Unmodified-Since" is used with a method The request-header field "If-Unmodified-Since" is used with a method
to make it conditional. If the requested resource has not been to make it 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).
skipping to change at page 16, line 38 skipping to change at page 17, line 5
If the request normally (i.e., without the If-Unmodified-Since If the request normally (i.e., without the If-Unmodified-Since
header) would result in anything other than a 2xx or 412 status, the header) would result in anything other than a 2xx or 412 status, the
If-Unmodified-Since header SHOULD be ignored. If-Unmodified-Since header SHOULD be ignored.
If the specified date is invalid, the header is ignored. If the specified date is invalid, the header is ignored.
The result of a request having both an If-Unmodified-Since header The result of a request having both an If-Unmodified-Since header
field and either an If-None-Match or an If-Modified-Since header field and either an If-None-Match or an If-Modified-Since header
fields is undefined by this specification. fields is undefined by this specification.
7.6. Last-Modified 6.6. Last-Modified
The entity-header field "Last-Modified" indicates the date and time The entity-header field "Last-Modified" 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
skipping to change at page 17, line 29 skipping to change at page 17, line 44
its response. This allows a recipient to make an accurate assessment its response. This allows a recipient to make an accurate assessment
of the entity's modification time, especially if the entity changes of the entity's modification time, especially if the entity changes
near the time that the response is generated. near the time that the response is generated.
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
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.
8. IANA Considerations 7. IANA Considerations
8.1. Message Header Registration 7.1. 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 7.1 | | ETag | http | standard | Section 6.1 |
| If-Match | http | standard | Section 7.2 | | If-Match | http | standard | Section 6.2 |
| If-Modified-Since | http | standard | Section 7.3 | | If-Modified-Since | http | standard | Section 6.3 |
| If-None-Match | http | standard | Section 7.4 | | If-None-Match | http | standard | Section 6.4 |
| If-Unmodified-Since | http | standard | Section 7.5 | | If-Unmodified-Since | http | standard | Section 6.5 |
| Last-Modified | http | standard | Section 7.6 | | Last-Modified | http | standard | Section 6.6 |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
9. Security Considerations 8. Security Considerations
No additional security considerations have been identified beyond No additional security considerations have been identified beyond
those applicable to HTTP in general [Part1]. those applicable to HTTP in general [Part1].
10. Acknowledgments 9. Acknowledgments
11. References 10. References
11.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-05 and Message Parsing", draft-ietf-httpbis-p1-messaging-06
(work in progress), November 2008. (work in progress), March 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-05 (work Partial Responses", draft-ietf-httpbis-p5-range-06 (work
in progress), November 2008. in progress), March 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.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-05 (work in progress), draft-ietf-httpbis-p6-cache-06 (work in progress),
November 2008. March 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.
11.2. Informative References [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
Appendix A. Compatibility with Previous Versions Appendix A. Compatibility with Previous Versions
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 5 and 7.4). (Sections 4 and 6.4).
Appendix B. Change Log (to be removed by RFC Editor before publication) Appendix B. Collected ABNF
B.1. Since RFC2616 ETag = "ETag:" OWS ETag-v
ETag-v = entity-tag
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1>
If-Match = "If-Match:" OWS If-Match-v
If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v
If-Modified-Since-v = HTTP-date
If-None-Match = "If-None-Match:" OWS If-None-Match-v
If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Unmodified-Since = "If-Unmodified-Since:" OWS
If-Unmodified-Since-v
If-Unmodified-Since-v = HTTP-date
Last-Modified = "Last-Modified:" OWS Last-Modified-v
Last-Modified-v = HTTP-date
OWS = <OWS, defined in [Part1], Section 1.2.2>
entity-tag = [ weak ] opaque-tag
opaque-tag = quoted-string
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
weak = "W/"
ABNF diagnostics:
; ETag defined but not used
; If-Match defined but not used
; If-Modified-Since defined but not used
; If-None-Match defined but not used
; If-Unmodified-Since defined but not used
; Last-Modified defined but not used
Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
B.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"
Other changes: Other changes:
o Move definitions of 304 and 412 condition codes from Part2. o Move definitions of 304 and 412 condition codes from Part2.
B.3. Since draft-ietf-httpbis-p4-conditional-01 C.3. Since draft-ietf-httpbis-p4-conditional-01
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 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.
B.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 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 registrations for headers
defined in this document. defined in this document.
B.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"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068 o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068
Date header reference" Date header reference"
B.6. Since draft-ietf-httpbis-p4-conditional-04 C.6. Since draft-ietf-httpbis-p4-conditional-04
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. value format definitions.
C.7. Since draft-ietf-httpbis-p4-conditional-05
Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Add appendix containing collected and expanded ABNF, reorganize
ABNF introduction.
Index Index
3 3
304 Not Modified (status code) 5 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
G G
Grammar Grammar
entity-tag 5 entity-tag 5
ETag 11 ETag 11
ETag-v 11 ETag-v 11
If-Match 12 If-Match 12
If-Match-v 12 If-Match-v 12
If-Modified-Since 13 If-Modified-Since 13
If-Modified-Since-v 13 If-Modified-Since-v 13
If-None-Match 15 If-None-Match 15
If-None-Match-v 15 If-None-Match-v 15
If-Unmodified-Since 16 If-Unmodified-Since 16
If-Unmodified-Since-v 16 If-Unmodified-Since-v 16
Last-Modified 16 Last-Modified 17
Last-Modified-v 16 Last-Modified-v 17
opaque-tag 5 opaque-tag 5
weak 5 weak 5
H H
Headers Headers
ETag 11 ETag 11
If-Match 12 If-Match 12
If-Modified-Since 13 If-Modified-Since 13
If-None-Match 14 If-None-Match 15
If-Unmodified-Since 16 If-Unmodified-Since 16
Last-Modified 16 Last-Modified 17
I I
If-Match header 12 If-Match header 12
If-Modified-Since header 13 If-Modified-Since header 13
If-None-Match header 14 If-None-Match header 15
If-Unmodified-Since header 16 If-Unmodified-Since header 16
L L
Last-Modified header 16 Last-Modified header 17
S S
Status Codes Status Codes
304 Not Modified 5 304 Not Modified 6
412 Precondition Failed 6 412 Precondition Failed 6
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
skipping to change at page 24, line 4 skipping to change at line 1114
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 71 change blocks. 
116 lines changed or deleted 204 lines changed or added

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