draft-ietf-httpbis-p4-conditional-24.txt   draft-ietf-httpbis-p4-conditional-25.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: March 29, 2014 September 25, 2013 Expires: May 21, 2014 November 17, 2013
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
draft-ietf-httpbis-p4-conditional-24 draft-ietf-httpbis-p4-conditional-25
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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.5. The changes in this draft are summarized in Appendix D.1.
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 March 29, 2014. This Internet-Draft will expire on May 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 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 . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 9
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 45 skipping to change at page 3, line 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
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-19 . . . . . . . . 25 D.1. Since draft-ietf-httpbis-p4-conditional-24 . . . . . . . . 25
D.2. Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 26 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
D.3. Since draft-ietf-httpbis-p4-conditional-21 . . . . . . . . 26
D.4. Since draft-ietf-httpbis-p4-conditional-22 . . . . . . . . 26
D.5. Since draft-ietf-httpbis-p4-conditional-23 . . . . . . . . 27
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
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 5, line 30 skipping to change at page 5, line 30
validators are ideal for comparisons but can be very difficult (and validators are ideal for comparisons but can be very difficult (and
occasionally impossible) to generate efficiently. Rather than impose occasionally impossible) to generate efficiently. Rather than impose
that all forms of resource adhere to the same strength of validator, that all forms of resource adhere to the same strength of validator,
HTTP exposes the type of validator in use and imposes restrictions on HTTP exposes the type of validator in use and imposes restrictions on
when weak validators can be used as preconditions. when weak validators can be used as preconditions.
A "strong validator" is representation metadata that changes value A "strong validator" is representation metadata that changes value
whenever a change occurs to the representation data that would be whenever a change occurs to the representation data that would be
observable in the payload body of a 200 (OK) response to GET. observable in the payload body of a 200 (OK) response to GET.
A strong validator might change for other reasons, such as when a A strong validator might change for reasons other than a change to
semantically significant part of the representation metadata is the representation data, such as when a semantically significant part
changed (e.g., Content-Type), but it is in the best interests of the of the representation metadata is changed (e.g., Content-Type), but
origin server to only change the value when it is necessary to it is in the best interests of the origin server to only change the
invalidate the stored responses held by remote caches and authoring value when it is necessary to invalidate the stored responses held by
tools. A strong validator is unique across all representations of a remote caches and authoring tools.
given resource, such that no two representations of that resource can
share the same validator unless their representation data is
identical.
Cache entries might persist for arbitrarily long periods, regardless Cache entries might persist for arbitrarily long periods, regardless
of expiration times. Thus, a cache might attempt to validate an of expiration times. Thus, a cache might attempt to validate an
entry using a validator that it obtained in the distant past. A entry using a validator that it obtained in the distant past. A
strong validator is unique across all versions of all representations strong validator is unique across all versions of all representations
associated with a particular resource over time. However, there is associated with a particular resource over time. However, there is
no implication of uniqueness across representations of different no implication of uniqueness across representations of different
resources (i.e., the same strong validator might be in use for resources (i.e., the same strong validator might be in use for
representations of multiple resources at the same time and does not representations of multiple resources at the same time and does not
imply that those representations are equivalent). imply that those representations are equivalent).
skipping to change at page 12, line 5 skipping to change at page 12, line 5
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b" ETag: "123-b"
Content-Length: 43 Content-Length: 43
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Content-Encoding: gzip Content-Encoding: gzip
...binary data... ...binary data...
Note: Content codings are a property of the representation, so Note: Content codings are a property of the representation data,
therefore an entity-tag of an encoded representation has to be so a strong entity-tag for a content-encoded representation has to
distinct from an unencoded representation to prevent conflicts be distinct from the entity tag of an unencoded representation to
during cache updates and range requests. In contrast, transfer prevent potential conflicts during cache updates and range
codings (Section 4 of [Part1]) apply only during message transfer requests. In contrast, transfer codings (Section 4 of [Part1])
and do not require distinct entity-tags. apply only during message transfer and do not result in distinct
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, 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.
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
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-24 (work in progress), draft-ietf-httpbis-p1-messaging-25 (work in progress),
September 2013. November 2013.
[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-24 (work in progress), draft-ietf-httpbis-p2-semantics-25 (work in progress),
September 2013. November 2013.
[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-24 (work in progress), draft-ietf-httpbis-p5-range-25 (work in progress),
September 2013. November 2013.
[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-24 (work in progress), draft-ietf-httpbis-p6-cache-25 (work in progress),
September 2013. November 2013.
[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 31 skipping to change at page 25, line 31
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
obs-text = <obs-text, defined in [Part1], Section 3.2.6> obs-text = <obs-text, defined in [Part1], Section 3.2.6>
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
weak = %x57.2F ; W/ weak = %x57.2F ; W/
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
Changes up to the first Working Group Last Call draft are summarized Changes up to the IETF Last Call draft are summarized in <http://
in <http://tools.ietf.org/html/ tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-24#appendix-D>.
draft-ietf-httpbis-p4-conditional-19#appendix-C>.
D.1. Since draft-ietf-httpbis-p4-conditional-19
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to
clarify eval order/interaction of conditional headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required
headers on 304 and 206"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
of Conditional Request Support"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and
Conditional Requests"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
requirements for recipients"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional
Request Security Considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified-
Since lacks definition for method != GET"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor
conditional header field descriptions"
D.2. Since draft-ietf-httpbis-p4-conditional-20
o Conformance criteria and considerations regarding error handling
are now defined in Part 1.
D.3. Since draft-ietf-httpbis-p4-conditional-21
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/96>: "Conditional
GET text"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
of Conditional Request Support"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/384>: "unclear prose
in definition of 304"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/401>: "ETags and
Conneg"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/402>: "Comparison
function for If-Match and If-None-Match"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/406>: "304 without
validator"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/427>: "If-Match and
428"
D.4. Since draft-ietf-httpbis-p4-conditional-22
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
expansion in ABNF appendices"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/437>: "incorrect
example dates"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/461>: "Editorial
suggestions"
D.5. Since draft-ietf-httpbis-p4-conditional-23 D.1. Since draft-ietf-httpbis-p4-conditional-24
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/455>: "PUT + If- o <http://tools.ietf.org/wg/httpbis/trac/ticket/518>: "APPSDIR
Match over-constrained?" review of draft-ietf-httpbis-p4-conditional-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/479>: "MUSTs and
other feedback"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/495>: "p4 editorial
nits"
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
 End of changes. 15 change blocks. 
121 lines changed or deleted 33 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/