draft-ietf-httpbis-p4-conditional-25.txt   draft-ietf-httpbis-p4-conditional-26.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: May 21, 2014 November 17, 2013 Expires: August 10, 2014 February 6, 2014
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
draft-ietf-httpbis-p4-conditional-25 draft-ietf-httpbis-p4-conditional-26
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is a stateless application-
protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines HTTP/1.1 conditional requests, systems. This document defines HTTP/1.1 conditional requests,
including metadata header fields for indicating state changes, including metadata header fields for indicating state changes,
request header fields for making preconditions on such state, and request header fields for making preconditions on such state, and
rules for constructing the responses to a conditional request when rules for constructing the responses to a conditional request when
one or more preconditions evaluate to false. one or more preconditions evaluate to false.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <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 D.1. The changes in this draft are summarized in Appendix D.2.
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 May 21, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5
2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8
2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Example: Entity-tags Varying on Content-Negotiated 2.3.3. Example: Entity-tags Varying on Content-Negotiated
Resources . . . . . . . . . . . . . . . . . . . . . . 11 Resources . . . . . . . . . . . . . . . . . . . . . . 11
2.4. When to Use Entity-tags and Last-Modified Dates . . . . . 12 2.4. When to Use Entity-tags and Last-Modified Dates . . . . . 12
3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14
3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15
3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 46 skipping to change at page 3, line 46
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 23 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 23
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 24 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 24
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 25 publication) . . . . . . . . . . . . . . . . . . . . 25
D.1. Since draft-ietf-httpbis-p4-conditional-24 . . . . . . . . 25 D.1. Since draft-ietf-httpbis-p4-conditional-24 . . . . . . . . 25
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 D.2. Since draft-ietf-httpbis-p4-conditional-25 . . . . . . . . 25
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Conditional requests are HTTP requests [Part2] that include one or Conditional requests are HTTP requests [Part2] that include one or
more header fields indicating a precondition to be tested before more header fields indicating a precondition to be tested before
applying the method semantics to the target resource. This document applying the method semantics to the target resource. This document
defines the HTTP/1.1 conditional request mechanisms in terms of the defines the HTTP/1.1 conditional request mechanisms in terms of the
architecture, syntax notation, and conformance criteria defined in architecture, syntax notation, and conformance criteria defined in
[Part1]. [Part1].
skipping to change at page 4, line 48 skipping to change at page 4, line 48
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
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5 of [Part1]. defined in Section 2.5 of [Part1].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with the list rule extension defined in Section notation of [RFC5234] with a list extension, defined in Section 7 of
7 of [Part1]. Appendix B describes rules imported from other [Part1], that allows for compact definition of comma-separated lists
documents. Appendix C shows the collected ABNF with the list rule using a '#' operator (similar to how the '*' operator indicates
expanded. repetition). Appendix B describes rules imported from other
documents. Appendix C shows the collected grammar with all list
operators expanded to standard ABNF notation.
2. Validators 2. Validators
This specification defines two forms of metadata that are commonly This specification defines two forms of metadata that are commonly
used to observe resource state and test for preconditions: used to observe resource state and test for preconditions:
modification dates (Section 2.2) and opaque entity tags modification dates (Section 2.2) and opaque entity tags
(Section 2.3). Additional metadata that reflects resource state has (Section 2.3). Additional metadata that reflects resource state has
been defined by various extensions of HTTP, such as WebDAV [RFC4918], been defined by various extensions of HTTP, such as WebDAV [RFC4918],
that are beyond the scope of this specification. A resource metadata that are beyond the scope of this specification. A resource metadata
value is referred to as a "validator" when it is used within a value is referred to as a "validator" when it is used within a
skipping to change at page 10, line 14 skipping to change at page 10, line 19
accurate and efficient validation mechanism for that resource, and accurate and efficient validation mechanism for that resource, and
that any such mechanism can be mapped to a simple sequence of octets that any such mechanism can be mapped to a simple sequence of octets
for easy comparison. Since the value is opaque, there is no need for for easy comparison. Since the value is opaque, there is no need for
the client to be aware of how each entity-tag is constructed. the client to be aware of how each entity-tag is constructed.
For example, a resource that has implementation-specific versioning For example, a resource that has implementation-specific versioning
applied to all changes might use an internal revision number, perhaps applied to all changes might use an internal revision number, perhaps
combined with a variance identifier for content negotiation, to combined with a variance identifier for content negotiation, to
accurately differentiate between representations. Other accurately differentiate between representations. Other
implementations might use a collision-resistant hash of implementations might use a collision-resistant hash of
representation content, a combination of various filesystem representation content, a combination of various file attributes, or
attributes, or a modification timestamp that has sub-second a modification timestamp that has sub-second resolution.
resolution.
An origin server SHOULD send ETag for any selected representation for An origin server SHOULD send ETag for any selected representation for
which detection of changes can be reasonably and consistently which detection of changes can be reasonably and consistently
determined, since the entity-tag's use in conditional requests and determined, since the entity-tag's use in conditional requests and
evaluating cache freshness ([Part6]) can result in a substantial evaluating cache freshness ([Part6]) can result in a substantial
reduction of HTTP network traffic and can be a significant factor in reduction of HTTP network traffic and can be a significant factor in
improving service scalability and reliability. improving service scalability and reliability.
2.3.2. Comparison 2.3.2. Comparison
skipping to change at page 12, line 15 skipping to change at page 12, line 15
Note: Content codings are a property of the representation data, Note: Content codings are a property of the representation data,
so a strong entity-tag for a content-encoded representation has to so a strong entity-tag for a content-encoded representation has to
be distinct from the entity tag of an unencoded representation to be distinct from the entity tag of an unencoded representation to
prevent potential conflicts during cache updates and range prevent potential conflicts during cache updates and range
requests. In contrast, transfer codings (Section 4 of [Part1]) requests. In contrast, transfer codings (Section 4 of [Part1])
apply only during message transfer and do not result in distinct apply only during message transfer and do not result in distinct
entity-tags. entity-tags.
2.4. When to Use Entity-tags and Last-Modified Dates 2.4. When to Use Entity-tags and Last-Modified Dates
We adopt a set of rules and recommendations for origin servers,
clients, and caches regarding when various validator types ought to
be used, and for what purposes.
In 200 (OK) responses to GET or HEAD, an origin server: In 200 (OK) responses to GET or HEAD, an origin server:
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.
skipping to change at page 22, line 22 skipping to change at page 22, line 22
| If-Unmodified-Since | http | standard | Section 3.4 | | If-Unmodified-Since | http | standard | Section 3.4 |
| Last-Modified | http | standard | Section 2.2 | | Last-Modified | http | standard | Section 2.2 |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
8. Security Considerations 8. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns specific to the HTTP/1.1 and users of known security concerns specific to the HTTP conditional
conditional request mechanisms. More general security considerations request mechanisms. More general security considerations are
are addressed in HTTP messaging [Part1] and semantics [Part2]. addressed in HTTP messaging [Part1] and semantics [Part2].
The validators defined by this specification are not intended to The validators defined by this specification are not intended to
ensure the validity of a representation, guard against malicious ensure the validity of a representation, guard against malicious
changes, or detect man-in-the-middle attacks. At best, they enable changes, or detect man-in-the-middle attacks. At best, they enable
more efficient cache updates and optimistic concurrent writes when more efficient cache updates and optimistic concurrent writes when
all participants are behaving nicely. At worst, the conditions will all participants are behaving nicely. At worst, the conditions will
fail and the client will receive a response that is no more harmful fail and the client will receive a response that is no more harmful
than an HTTP exchange without conditional requests. than an HTTP exchange without conditional requests.
An entity-tag can be abused in ways that create privacy risks. For An entity-tag can be abused in ways that create privacy risks. For
skipping to change at page 23, line 8 skipping to change at page 23, line 8
9. Acknowledgments 9. Acknowledgments
See Section 10 of [Part1]. See Section 10 of [Part1].
10. References 10. References
10.1. Normative References 10.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-25 (work in progress), draft-ietf-httpbis-p1-messaging-26 (work in progress),
November 2013. February 2014.
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-25 (work in progress), draft-ietf-httpbis-p2-semantics-26 (work in progress),
November 2013. February 2014.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-25 (work in progress), draft-ietf-httpbis-p5-range-26 (work in progress),
November 2013. February 2014.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-25 (work in progress), draft-ietf-httpbis-p6-cache-26 (work in progress),
November 2013. February 2014.
[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
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
skipping to change at page 25, line 41 skipping to change at page 25, line 41
Changes up to the IETF Last Call draft are summarized in <http:// Changes up to the IETF Last Call draft are summarized in <http://
tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-24#appendix-D>. tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-24#appendix-D>.
D.1. Since draft-ietf-httpbis-p4-conditional-24 D.1. Since draft-ietf-httpbis-p4-conditional-24
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/518>: "APPSDIR o <http://tools.ietf.org/wg/httpbis/trac/ticket/518>: "APPSDIR
review of draft-ietf-httpbis-p4-conditional-24" review of draft-ietf-httpbis-p4-conditional-24"
D.2. Since draft-ietf-httpbis-p4-conditional-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
Index Index
3 3
304 Not Modified (status code) 18 304 Not Modified (status code) 18
4 4
412 Precondition Failed (status code) 18 412 Precondition Failed (status code) 18
E E
ETag header field 9 ETag header field 9
 End of changes. 17 change blocks. 
31 lines changed or deleted 42 lines changed or added

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