| draft-ietf-httpbis-p4-conditional-19.txt |  | draft-ietf-httpbis-p4-conditional-20.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) Y. Lafon, Ed. |  | Obsoletes: 2616 (if approved) Y. Lafon, Ed. |
| Intended status: Standards Track W3C |  | Intended status: Standards Track W3C |
| Expires: September 13, 2012 J. Reschke, Ed. |  | Expires: January 17, 2013 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| March 12, 2012 |  | July 16, 2012 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-19 |  | draft-ietf-httpbis-p4-conditional-20 |
| 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. HTTP has been in use by the World Wide Web global |  | systems. This document defines HTTP/1.1 conditional requests, |
| information initiative since 1990. This document is Part 4 of the |  | including metadata header fields for indicating state changes, |
| seven-part specification that defines the protocol referred to as |  | request header fields for making preconditions on such state, and |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. |  | rules for constructing the responses to a conditional request when |
|  |  | one or more preconditions evaluate to false. |
| Part 4 defines request header fields for indicating conditional |  |  |
| requests and the rules for constructing responses to those requests. |  |  |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft takes place on the HTTPBIS working group |
| 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 C.20. |  | 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 September 13, 2012. |  | This Internet-Draft will expire on January 17, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2012 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 2, line 43 |  | skipping to change at page 3, line 11 |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |
| 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6 |
| 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8 |
| 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 . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 |
| 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. Rules for When to Use Entity-tags and Last-Modified |  | 2.4. Rules for When to Use Entity-tags and Last-Modified |
| Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |  | 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |
| 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |  | 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |
| 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 |  | 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 |
| 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |  | 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |
| 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 |
| skipping to change at page 3, line 16 |  | skipping to change at page 3, line 31 |
| Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |  | 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |
| 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |  | 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |
| 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 |  | 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 |
| 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |  | 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |
| 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 |
| 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19 |  | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 |  | 5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.2. Header Field Registration . . . . . . . . . . . . . . . . 19 |  | 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 |  | 6.2. Header Field Registration . . . . . . . . . . . . . . . . 21 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 23 |
| publication) . . . . . . . . . . . . . . . . . . . . 22 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 23 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 |  | Appendix D. Change Log (to be removed by RFC Editor before |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 |  | publication) . . . . . . . . . . . . . . . . . . . . 24 |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 |  | D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 24 |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 |  |  |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 |  |  |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 |  |  |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 |  |  |
| C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 |  |  |
| C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 |  |  |
| C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 |  |  |
| C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 |  |  |
| C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 |  |  |
| C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 |  |  |
| C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25 |  |  |
| C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 25 |  |  |
| C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 25 |  |  |
| C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 25 |  |  |
| C.19. Since draft-ietf-httpbis-p4-conditional-17 . . . . . . . . 26 |  |  |
| C.20. Since draft-ietf-httpbis-p4-conditional-18 . . . . . . . . 26 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  |  |
| 1. Introduction |  | 1. Introduction |
| This document defines the HTTP/1.1 conditional request mechanisms, |  | Conditional requests are HTTP requests [Part2] that include one or |
| including both metadata for indicating/observing changes in resource |  | more header fields indicating a precondition to be tested before |
| representations and request header fields that specify preconditions |  | applying the method semantics to the target resource. Each |
| on that metadata be checked before performing the request method. |  | precondition is based on metadata that is expected to change if the |
|  |  | selected representation of the target resource is changed. This |
|  |  | document defines the HTTP/1.1 conditional request mechanisms in terms |
|  |  | of the architecture, syntax notation, and conformance criteria |
|  |  | defined in [Part1]. |
| Conditional GET requests are the most efficient mechanism for HTTP |  | Conditional GET requests are the most efficient mechanism for HTTP |
| cache updates [Part6]. Conditionals can also be applied to state- |  | cache updates [Part6]. Conditionals can also be applied to state- |
| changing methods, such as PUT and DELETE, to prevent the "lost |  | changing methods, such as PUT and DELETE, to prevent the "lost |
| update" problem: one client accidentally overwriting the work of |  | update" problem: one client accidentally overwriting the work of |
| another client that has been acting in parallel. |  | another client that has been acting in parallel. |
| Conditional request preconditions are based on the state of the |  | Conditional request preconditions are based on the state of the |
| target resource as a whole (its current value set) or the state as |  | target resource as a whole (its current value set) or the state as |
| observed in a previously obtained representation (one value in that |  | observed in a previously obtained representation (one value in that |
| set). A resource might have multiple current representations, each |  | set). A resource might have multiple current representations, each |
| skipping to change at page 4, line 42 |  | skipping to change at page 4, line 47 |
| conditional request preconditions are evaluated by comparing the |  | conditional request preconditions are evaluated by comparing the |
| values provided in the request header fields to the current metadata |  | values provided in the request header fields to the current metadata |
| for the selected representation. |  | for the selected representation. |
| 1.1. Conformance and Error Handling |  | 1.1. Conformance and Error Handling |
| 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]. |
| This document defines conformance criteria for several roles in HTTP |  | This specification targets conformance criteria according to the role |
| communication, including Senders, Recipients, Clients, Servers, User- |  | of a participant in HTTP communication. Hence, HTTP requirements are |
| Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |  | placed on senders, recipients, clients, servers, user agents, |
| Section 2 of [Part1] for definitions of these terms. |  | intermediaries, origin servers, proxies, gateways, or caches, |
|  |  | depending on what behavior is being constrained by the requirement. |
|  |  | See Section 2 of [Part1] for definitions of these terms. |
|  |  | The verb "generate" is used instead of "send" where a requirement |
|  |  | differentiates between creating a protocol element and merely |
|  |  | forwarding a received element downstream. |
| An implementation is considered conformant if it complies with all of |  | An implementation is considered conformant if it complies with all of |
| the requirements associated with its role(s). Note that SHOULD-level |  | the requirements associated with the roles it partakes in HTTP. Note |
| requirements are relevant here, unless one of the documented |  | that SHOULD-level requirements are relevant here, unless one of the |
| exceptions is applicable. |  | documented exceptions is applicable. |
| This document also uses ABNF to define valid protocol elements |  | This document also uses ABNF to define valid protocol elements |
| (Section 1.2). In addition to the prose requirements placed upon |  | (Section 1.2). In addition to the prose requirements placed upon |
| them, Senders MUST NOT generate protocol elements that are invalid. |  | them, senders MUST NOT generate protocol elements that do not match |
|  |  | the grammar defined by the ABNF rules for those protocol elements |
|  |  | that are applicable to the sender's role. If a received protocol |
|  |  | element is processed, the recipient MUST be able to parse any value |
|  |  | that would match the ABNF rules for that protocol element, excluding |
|  |  | only those rules not applicable to the recipient's role. |
| Unless noted otherwise, Recipients MAY take steps to recover a usable |  | Unless noted otherwise, a recipient MAY attempt to recover a usable |
| protocol element from an invalid construct. However, HTTP does not |  | protocol element from an invalid construct. HTTP does not define |
| define specific error handling mechanisms, except in cases where it |  | specific error handling mechanisms except when they have a direct |
| has direct impact on security. This is because different uses of the |  | impact on security, since different applications of the protocol |
| protocol require different error handling strategies; for example, a |  | require different error handling strategies. For example, a Web |
| Web browser may wish to transparently recover from a response where |  | browser might wish to transparently recover from a response where the |
| the Location header field doesn't parse according to the ABNF, |  | Location header field doesn't parse according to the ABNF, whereas a |
| whereby in a systems control protocol using HTTP, this type of error |  | systems control client might consider any form of error recovery to |
| recovery could lead to dangerous consequences. |  | be dangerous. |
| 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 the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix B shows the collected ABNF with the list |  | 1.2 of [Part1]. Appendix B describes rules imported from other |
| rule expanded. |  | documents. Appendix C shows the collected ABNF with the list rule |
|  |  | expanded. |
| The following core rules are included by reference, as defined in |  |  |
| [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), and VCHAR (any visible US-ASCII |  |  |
| character). |  |  |
| The ABNF rules below are defined in [Part1] and [Part2]: |  |  |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  |  |
| obs-text = <obs-text, defined in [Part1], Section 3.2.4> |  |  |
| HTTP-date = <HTTP-date, defined in [Part2], Section 8> |  |  |
| 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 and opaque entity tags. Additional metadata that |  | modification dates (Section 2.2) and opaque entity tags |
| reflects resource state has been defined by various extensions of |  | (Section 2.3). Additional metadata that reflects resource state has |
| HTTP, such as WebDAV [RFC4918], that are beyond the scope of this |  | been defined by various extensions of HTTP, such as WebDAV [RFC4918], |
| specification. A resource metadata value is referred to as a |  | that are beyond the scope of this specification. A resource metadata |
| "validator" when it is used within a precondition. |  | value is referred to as a "validator" when it is used within a |
|  |  | precondition. |
| 2.1. Weak versus Strong |  | 2.1. Weak versus Strong |
| Validators come in two flavors: strong or weak. Weak validators are |  | Validators come in two flavors: strong or weak. Weak validators are |
| easy to generate but are far less useful for comparisons. Strong |  | easy to generate but are far less useful for comparisons. Strong |
| 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 a representation metadata value that MUST be |  | A "strong validator" is a representation metadata value that MUST be |
| changed to a new, previously unused or guaranteed unique, value |  | changed to a new, previously unused or guaranteed unique, value |
| whenever a change occurs to the representation data such that a |  | whenever a change occurs to the representation data such that a |
| change would be observable in the payload body of a 200 response to |  | change would be observable in the payload body of a 200 (OK) response |
| GET. A strong validator MAY be changed for other reasons, such as |  | to GET. |
| when a semantically significant part of the representation metadata |  |  |
| is changed (e.g., Content-Type), but it is in the best interests of |  | A strong validator MAY be changed for other reasons, such as when a |
| the origin server to only change the value when it is necessary to |  | semantically significant part of the representation metadata is |
|  |  | changed (e.g., Content-Type), but it is in the best interests of the |
|  |  | origin server to only change the value when it is necessary to |
| invalidate the stored responses held by remote caches and authoring |  | invalidate the stored responses held by remote caches and authoring |
| tools. A strong validator MUST be unique across all representations |  | tools. A strong validator MUST be unique across all representations |
| of a given resource, such that no two representations of that |  | of a given resource, such that no two representations of that |
| resource share the same validator unless their payload body would be |  | resource share the same validator unless their payload body would be |
| identical. |  | 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 MUST be unique across all versions of all |  | strong validator MUST be unique across all versions of all |
| representations associated with a particular resource over time. |  | representations associated with a particular resource over time. |
| However, there is no implication of uniqueness across representations |  | However, there is no implication of uniqueness across representations |
| of different resources (i.e., the same strong validator might be in |  | of different resources (i.e., the same strong validator might be in |
| use for representations of multiple resources at the same time and |  | use for representations of multiple resources at the same time and |
| does not imply that those representations are equivalent). |  | does not imply that those representations are equivalent). |
| There are a variety of strong validators used in practice. The best |  | There are a variety of strong validators used in practice. The best |
| are based on strict revision control, wherein each change to a |  | are based on strict revision control, wherein each change to a |
| representation always results in a unique node name and revision |  | representation always results in a unique node name and revision |
| identifier being assigned before the representation is made |  | identifier being assigned before the representation is made |
| accessible to GET. A cryptographic hash function applied to the |  | accessible to GET. A collision-resistant hash function applied to |
| representation data is also sufficient if the data is available prior |  | the representation data is also sufficient if the data is available |
| to the response header fields being sent and the digest does not need |  | prior to the response header fields being sent and the digest does |
| to be recalculated every time a validation request is received. |  | not need to be recalculated every time a validation request is |
| However, if a resource has distinct representations that differ only |  | received. However, if a resource has distinct representations that |
| in their metadata, such as might occur with content negotiation over |  | differ only in their metadata, such as might occur with content |
| media types that happen to share the same data format, then a server |  | negotiation over media types that happen to share the same data |
| SHOULD incorporate additional information in the validator to |  | format, then the origin server SHOULD incorporate additional |
| distinguish those representations and avoid confusing cache behavior. |  | information in the validator to distinguish those representations and |
|  |  | avoid confusing cache behavior. |
| In contrast, a "weak validator" is a representation metadata value |  | In contrast, a "weak validator" is a representation metadata value |
| that might not be changed for every change to the representation |  | that might not be changed for every change to the representation |
| data. This weakness might be due to limitations in how the value is |  | data. This weakness might be due to limitations in how the value is |
| calculated, such as clock resolution or an inability to ensure |  | calculated, such as clock resolution or an inability to ensure |
| uniqueness for all possible representations of the resource, or due |  | uniqueness for all possible representations of the resource, or due |
| to a desire by the resource owner to group representations by some |  | to a desire by the resource owner to group representations by some |
| self-determined set of equivalency rather than unique sequences of |  | self-determined set of equivalency rather than unique sequences of |
| data. A weak entity-tag SHOULD change whenever the origin server |  | data. An origin server SHOULD change a weak entity-tag whenever it |
| considers prior representations to be unacceptable as a substitute |  | considers prior representations to be unacceptable as a substitute |
| for the current representation. In other words, a weak entity-tag |  | for the current representation. In other words, a weak entity-tag |
| SHOULD change whenever the origin server wants caches to invalidate |  | ought to change whenever the origin server wants caches to invalidate |
| old responses. |  | old responses. |
| For example, the representation of a weather report that changes in |  | For example, the representation of a weather report that changes in |
| content every second, based on dynamic measurements, might be grouped |  | content every second, based on dynamic measurements, might be grouped |
| into sets of equivalent representations (from the origin server's |  | into sets of equivalent representations (from the origin server's |
| perspective) with the same weak validator in order to allow cached |  | perspective) with the same weak validator in order to allow cached |
| representations to be valid for a reasonable period of time (perhaps |  | representations to be valid for a reasonable period of time (perhaps |
| adjusted dynamically based on server load or weather quality). |  | adjusted dynamically based on server load or weather quality). |
| Likewise, a representation's modification time, if defined with only |  | Likewise, a representation's modification time, if defined with only |
| one-second resolution, might be a weak validator if it is possible |  | one-second resolution, might be a weak validator if it is possible |
| skipping to change at page 8, line 16 |  | skipping to change at page 8, line 25 |
| resource interface. The last-modified time would usually be the most |  | resource interface. The last-modified time would usually be the most |
| recent time that any of those parts were changed. How that value is |  | recent time that any of those parts were changed. How that value is |
| determined for any given resource is an implementation detail beyond |  | determined for any given resource is an implementation detail beyond |
| the scope of this specification. What matters to HTTP is how |  | the scope of this specification. What matters to HTTP is how |
| recipients of the Last-Modified header field can use its value to |  | recipients of the Last-Modified header field can use its value to |
| make conditional requests and test the validity of locally cached |  | make conditional requests and test the validity of locally cached |
| responses. |  | responses. |
| An origin server SHOULD obtain the Last-Modified value of the |  | An origin server SHOULD obtain the Last-Modified value of the |
| representation as close as possible to the time that it generates the |  | representation as close as possible to the time that it generates the |
| Date field-value for its response. This allows a recipient to make |  | Date field value for its response. This allows a recipient to make |
| an accurate assessment of the representation's modification time, |  | an accurate assessment of the representation's modification time, |
| especially if the representation changes near the time that the |  | especially if the representation changes near the time that the |
| response is generated. |  | response is generated. |
| An origin server with a clock MUST NOT send a Last-Modified date that |  | An origin server with a clock MUST NOT send a Last-Modified date that |
| is later than the server's time of message origination (Date). If |  | is later than the server's time of message origination (Date). If |
| the last modification time is derived from implementation-specific |  | the last modification time is derived from implementation-specific |
| metadata that evaluates to some time in the future, according to the |  | metadata that evaluates to some time in the future, according to the |
| origin server's clock, then the origin server MUST replace that value |  | origin server's clock, then the origin server MUST replace that value |
| with the message origination date. This prevents a future |  | with the message origination date. This prevents a future |
| skipping to change at page 9, line 34 |  | skipping to change at page 9, line 41 |
| same Last-Modified time, then at least one of those responses would |  | same Last-Modified time, then at least one of those responses would |
| have a Date value equal to its Last-Modified time. The arbitrary 60- |  | have a Date value equal to its Last-Modified time. The arbitrary 60- |
| second limit guards against the possibility that the Date and Last- |  | second limit guards against the possibility that the Date and Last- |
| Modified values are generated from different clocks, or at somewhat |  | Modified values are generated from different clocks, or at somewhat |
| different times during the preparation of the response. An |  | different times during the preparation of the response. An |
| implementation MAY use a value larger than 60 seconds, if it is |  | implementation MAY use a value larger than 60 seconds, if it is |
| believed that 60 seconds is too short. |  | believed that 60 seconds is too short. |
| 2.3. ETag |  | 2.3. ETag |
| The ETag header field provides the current entity-tag for the |  | The "ETag" header field provides the current entity-tag for the |
| selected representation. An entity-tag is an opaque validator for |  | selected representation. An entity-tag is an opaque validator for |
| differentiating between multiple representations of the same |  | differentiating between multiple representations of the same |
| resource, regardless of whether those multiple representations are |  | resource, regardless of whether those multiple representations are |
| due to resource state changes over time, content negotiation |  | due to resource state changes over time, content negotiation |
| resulting in multiple representations being valid at the same time, |  | resulting in multiple representations being valid at the same time, |
| or both. An entity-tag consists of an opaque quoted string, possibly |  | or both. An entity-tag consists of an opaque quoted string, possibly |
| prefixed by a weakness indicator. |  | prefixed by a weakness indicator. |
| ETag = entity-tag |  | ETag = entity-tag |
| skipping to change at page 10, line 42 |  | skipping to change at page 10, line 50 |
| knows the implementation of a resource well enough to select the most |  | knows the implementation of a resource well enough to select the most |
| 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 stored hash of representation content, a |  | implementations might use a collision-resistant hash of |
| combination of various filesystem attributes, or a modification |  | representation content, a combination of various filesystem |
| timestamp that has sub-second resolution. |  | attributes, or a modification timestamp that has sub-second |
|  |  | resolution. |
| Origin servers SHOULD send ETag for any selected representation for |  | Origin servers 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 11, line 33 |  | skipping to change at page 11, line 41 |
| | 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 | |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| 2.3.3. Example: Entity-tags varying on Content-Negotiated Resources |  | 2.3.3. Example: Entity-tags varying on Content-Negotiated Resources |
| Consider a resource that is subject to content negotiation (Section 5 |  | Consider a resource that is subject to content negotiation (Section 8 |
| of [Part3]), and where the representations returned upon a GET |  | of [Part2]), and where the representations returned upon a GET |
| request vary based on the Accept-Encoding request header field |  | request vary based on the Accept-Encoding request header field |
| (Section 6.3 of [Part3]): |  | (Section 9.3 of [Part2]): |
| >> Request: |  | >> Request: |
| GET /index HTTP/1.1 |  | GET /index HTTP/1.1 |
| Host: www.example.com |  | Host: www.example.com |
| Accept-Encoding: gzip |  | Accept-Encoding: gzip |
| In this case, the response might or might not use the gzip content |  | In this case, the response might or might not use the gzip content |
| coding. If it does not, the response might look like: |  | coding. If it does not, the response might look like: |
| skipping to change at page 12, line 36 |  | skipping to change at page 12, line 39 |
| Date: Thu, 26 Mar 2010 00:05:00 GMT |  | Date: Thu, 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, so |
| therefore an entity-tag of an encoded representation must be |  | therefore an entity-tag of an encoded representation has to be |
| distinct from an unencoded representation to prevent conflicts |  | distinct from an unencoded representation to prevent conflicts |
| during cache updates and range requests. In contrast, transfer |  | during cache updates and range requests. In contrast, transfer |
| codings (Section 4 of [Part1]) apply only during message transfer |  | codings (Section 4 of [Part1]) apply only during message transfer |
| and do not require distinct entity-tags. |  | and do not require distinct entity-tags. |
| 2.4. Rules for When to Use Entity-tags and Last-Modified Dates |  | 2.4. 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. |
| skipping to change at page 14, line 8 |  | skipping to change at page 14, line 11 |
| Note: The general principle behind these rules is that HTTP/1.1 |  | Note: The general principle behind these rules is that HTTP/1.1 |
| servers and clients ought to transmit as much non-redundant |  | servers and clients ought to transmit as much non-redundant |
| information as is available in their responses and requests. |  | information as is available in their responses and requests. |
| HTTP/1.1 systems receiving this information will make the most |  | HTTP/1.1 systems receiving this information will make the most |
| conservative assumptions about the validators they receive. |  | conservative assumptions about the validators they receive. |
| HTTP/1.0 clients and caches might ignore entity-tags. Generally, |  | HTTP/1.0 clients and caches might 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 still ought to provide Last-Modified values. |
| 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 |  |  |
| origin servers should not provide one. |  |  |
| 3. Precondition Header Fields |  | 3. Precondition Header Fields |
| 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 for applying preconditions on requests. |  | fields for applying preconditions on requests. Section 5 defines the |
|  |  | order of evaluation when more than one precondition is present in a |
|  |  | request. |
| 3.1. If-Match |  | 3.1. If-Match |
| The "If-Match" header field MAY be used to make a request method |  | The "If-Match" header field can be used to make a request method |
| conditional on the current existence or value of an entity-tag for |  | conditional on the current existence or value of an entity-tag for |
| one or more representations of the target resource. If-Match is |  | one or more representations of the target resource. |
| generally useful for resource update requests, such as PUT requests, |  |  |
| as a means for protecting against accidental overwrites when multiple |  | If-Match is generally useful for resource update requests, such as |
| clients are acting in parallel on the same resource (i.e., the "lost |  | PUT requests, as a means for protecting against accidental overwrites |
| update" problem). An If-Match field-value of "*" places the |  | when multiple clients are acting in parallel on the same resource |
| precondition on the existence of any current representation for the |  | (i.e., the "lost update" problem). An If-Match field-value of "*" |
| target resource. |  | places the precondition on the existence of any current |
|  |  | representation for the target resource. |
| If-Match = "*" / 1#entity-tag |  | If-Match = "*" / 1#entity-tag |
| If any of the entity-tags listed in the If-Match field value match |  | The If-Match condition is met if and only if any of the entity-tags |
| (as per Section 2.3.2) the entity-tag of the selected representation |  | listed in the If-Match field value match the entity-tag of the |
| for the target resource, or if "*" is given and any current |  | selected representation for the target resource (as per |
| representation exists for the target resource, then the server MAY |  | Section 2.3.2), or if "*" is given and any current representation |
| perform the request method as if the If-Match header field was not |  | exists for the target resource. |
| present. |  |  |
| If none of the entity-tags match, or if "*" is given and no current |  | If the condition is met, the server MAY perform the request method as |
| representation exists, the server MUST NOT perform the requested |  | if the If-Match header field was not present. |
| method. Instead, the server MUST respond with the 412 (Precondition |  |  |
|  |  | Origin servers MUST NOT perform the requested method if the condition |
|  |  | is not met; instead they MUST respond with the 412 (Precondition |
| Failed) status code. |  | Failed) status code. |
|  |  | Proxy servers using a cached response as the selected representation |
|  |  | MUST NOT perform the requested method if the condition is not met; |
|  |  | instead, they MUST forward the request towards the origin server. |
| If the request would, without the If-Match header field, result in |  | If the request would, without the If-Match header field, result in |
| anything other than a 2xx or 412 status code, then the If-Match |  | anything other than a 2xx (Successful) or 412 (Precondition Failed) |
| header field MUST be ignored. |  | status code, then the If-Match header field MUST be ignored. |
| 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 |  |  |
| either an If-None-Match or an If-Modified-Since header field is |  |  |
| undefined by this specification. |  |  |
| 3.2. If-None-Match |  | 3.2. If-None-Match |
| The "If-None-Match" header field MAY be used to make a request method |  | The "If-None-Match" header field can be used to make a request method |
| conditional on not matching any of the current entity-tag values for |  | conditional on not matching any of the current entity-tag values for |
| representations of the target resource. If-None-Match is primarily |  | representations of the target resource. |
| used in conditional GET requests to enable efficient updates of |  |  |
| cached information with a minimum amount of transaction overhead. A |  |  |
| client that has one or more representations previously obtained from |  |  |
| the target resource can send If-None-Match with a list of the |  |  |
| associated entity-tags in the hope of receiving a 304 response if at |  |  |
| least one of those representations matches the selected |  |  |
| representation. |  |  |
| If-None-Match MAY also be used with a value of "*" to prevent an |  | If-None-Match is primarily used in conditional GET requests to enable |
|  |  | efficient updates of cached information with a minimum amount of |
|  |  | transaction overhead. A client that has one or more representations |
|  |  | previously obtained from the target resource can send If-None-Match |
|  |  | with a list of the associated entity-tags in the hope of receiving a |
|  |  | 304 (Not Modified) response if at least one of those representations |
|  |  | matches the selected representation. |
|  |  | If-None-Match can also be used with a value of "*" to prevent an |
| unsafe request method (e.g., PUT) from inadvertently modifying an |  | unsafe request method (e.g., PUT) from inadvertently modifying an |
| existing representation of the target resource when the client |  | existing representation of the target resource when the client |
| believes that the resource does not have a current representation. |  | believes that the resource does not have a current representation. |
| This is a variation on the "lost update" problem that might arise if |  | This is a variation on the "lost update" problem that might arise if |
| more than one client attempts to create an initial representation for |  | more than one client attempts to create an initial representation for |
| the target resource. |  | the target resource. |
| If-None-Match = "*" / 1#entity-tag |  | If-None-Match = "*" / 1#entity-tag |
| If any of the entity-tags listed in the If-None-Match field-value |  | The If-None-Match condition is met if and only if none of the entity- |
| match (as per Section 2.3.2) the entity-tag of the selected |  | tags listed in the If-None-Match field value match the entity-tag of |
| representation, or if "*" is given and any current representation |  | the selected representation for the target resource (as per |
| exists for that resource, then the server MUST NOT perform the |  | Section 2.3.2), or if "*" is given and no current representation |
|  |  | exists for that resource. |
|  |  | If the condition is not met, the server MUST NOT perform the |
| requested method. Instead, if the request method was GET or HEAD, |  | requested method. Instead, if the request method was GET or HEAD, |
| the server SHOULD respond with a 304 (Not Modified) status code, |  | the server SHOULD respond with a 304 (Not Modified) status code, |
| including the cache-related header fields (particularly ETag) of the |  | including the cache-related header fields (particularly ETag) of the |
| selected representation that has a matching entity-tag. For all |  | selected representation that has a matching entity-tag. For all |
| other request methods, the server MUST respond with a 412 |  | other request methods, the server MUST respond with a 412 |
| (Precondition Failed) status code. |  | (Precondition Failed) status code. |
| If none of the entity-tags match, then the server MAY perform the |  | If the condition is met, the server MAY perform the requested method |
| requested method as if the If-None-Match header field did not exist, |  | as if the If-None-Match header field did not exist, but MUST also |
| but MUST also ignore any If-Modified-Since header field(s) in the |  | ignore any If-Modified-Since header field(s) in the request. That |
| request. That is, if no entity-tags match, then the server MUST NOT |  | is, if no entity-tags match, then the server MUST NOT return a 304 |
| return a 304 (Not Modified) response. |  | (Not Modified) response. |
| If the request would, without the If-None-Match header field, result |  | If the request would, without the If-None-Match header field, result |
| in anything other than a 2xx or 304 status code, then the If-None- |  | in anything other than a 2xx (Successful) or 304 (Not Modified) |
| Match header field MUST be ignored. (See Section 2.4 for a |  | status code, then the If-None-Match header field MUST be ignored. |
| discussion of server behavior when both If-Modified-Since and If- |  | (See Section 2.4 for a discussion of server behavior when both If- |
| None-Match appear in the same request.) |  | Modified-Since and If-None-Match appear in the same request.) |
| 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 |  |  |
| either an If-Match or an If-Unmodified-Since header field is |  |  |
| undefined by this specification. |  |  |
| 3.3. If-Modified-Since |  | 3.3. If-Modified-Since |
| The "If-Modified-Since" header field MAY be used to make a request |  | The "If-Modified-Since" header field can be used with GET or HEAD to |
| method conditional by modification date: if the selected |  | make the method conditional by modification date: if the selected |
| representation has not been modified since the time specified in this |  | representation has not been modified since the time specified in this |
| field, then do not perform the request method; instead, respond as |  | field, then do not perform the request method; instead, respond as |
| detailed below. |  | detailed below. |
| If-Modified-Since = HTTP-date |  | If-Modified-Since = HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| skipping to change at page 17, line 34 |  | skipping to change at page 17, line 40 |
| Unsynchronized clocks and rounding problems, due to the different |  | Unsynchronized clocks and rounding problems, due to the different |
| encodings of time between the client and server, are concerns. |  | encodings of time between the client and server, are concerns. |
| This includes the possibility of race conditions if the document |  | This includes the possibility of race conditions if the document |
| has changed between the time it was first requested and the If- |  | has changed between the time it was first requested and the If- |
| Modified-Since date of a subsequent request, and the possibility |  | Modified-Since date of a subsequent request, and the possibility |
| of clock-skew-related problems if the If-Modified-Since date is |  | of clock-skew-related problems if the If-Modified-Since date is |
| derived from the client's clock without correction to the server's |  | derived from the client's clock without correction to the server's |
| clock. Corrections for different time bases between client and |  | clock. Corrections for different time bases between client and |
| server are at best approximate due to network latency. |  | server are at best approximate due to network latency. |
| The result of a request having both an If-Modified-Since header field |  |  |
| and either an If-Match or an If-Unmodified-Since header field is |  |  |
| undefined by this specification. |  |  |
| 3.4. If-Unmodified-Since |  | 3.4. If-Unmodified-Since |
| The "If-Unmodified-Since" header field MAY be used to make a request |  | The "If-Unmodified-Since" header field can be used to make a request |
| method conditional by modification date: if the selected |  | method conditional by modification date: if the selected |
| representation has been modified since the time specified in this |  | representation has been modified since the time specified in this |
| field, then the server MUST NOT perform the requested operation and |  | field, then the server MUST NOT perform the requested operation and |
| MUST instead respond with the 412 (Precondition Failed) status code. |  | MUST instead respond with the 412 (Precondition Failed) status code. |
| If the selected representation has not been modified since the time |  | If the selected representation has not been modified since the time |
| specified in this field, the server SHOULD perform the request method |  | specified in this field, the server SHOULD perform the request method |
| as if the If-Unmodified-Since header field were not present. |  | as if the If-Unmodified-Since header field were not present. |
| If-Unmodified-Since = HTTP-date |  | If-Unmodified-Since = HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| If the request normally (i.e., without the If-Unmodified-Since header |  | If a request normally (i.e., in absence of the If-Unmodified-Since |
| field) would result in anything other than a 2xx or 412 status code, |  | header field) would result in anything other than a 2xx (Successful) |
| the If-Unmodified-Since header field SHOULD be ignored. |  | or 412 (Precondition Failed) status code, the If-Unmodified-Since |
|  |  | header field SHOULD be ignored. |
| If the specified date is invalid, the header field MUST be ignored. |  | If the specified date is invalid, the header field MUST be ignored. |
| 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 is undefined by this specification. |  |  |
| 3.5. If-Range |  | 3.5. If-Range |
| The If-Range header field provides a special conditional request |  | The "If-Range" header field provides a special conditional request |
| mechanism that is similar to If-Match and If-Unmodified-Since but |  | mechanism that is similar to If-Match and If-Unmodified-Since but |
| specific to HTTP range requests. If-Range is defined in Section 5.3 |  | specific to HTTP range requests. If-Range is defined in Section 5.3 |
| of [Part5]. |  | of [Part5]. |
| 4. Status Code Definitions |  | 4. Status Code Definitions |
| 4.1. 304 Not Modified |  | 4.1. 304 Not Modified |
| The 304 status code indicates that a conditional GET request has been |  | The 304 status code indicates that a conditional GET request has been |
| received and would have resulted in a 200 (OK) response if it were |  | received and would have resulted in a 200 (OK) response if it were |
| not for the fact that the condition has evaluated to false. In other |  | not for the fact that the condition has evaluated to false. In other |
| words, there is no need for the server to transfer a representation |  | words, there is no need for the server to transfer a representation |
| of the target resource because the client's request indicates that it |  | of the target resource because the client's request indicates that it |
| already has a valid representation, as indicated by the 304 response |  | already has a valid representation, as indicated by the 304 response |
| header fields, and is therefore redirecting the client to make use of |  | header fields, and is therefore redirecting the client to make use of |
| that stored representation as if it were the payload of a 200 |  | that stored representation as if it were the payload of a 200 |
| response. The 304 response MUST NOT contain a message-body, and thus |  | response. The 304 response MUST NOT contain a message-body, and thus |
| is always terminated by the first empty line after the header fields. |  | is always terminated by the first empty line after the header fields. |
| A 304 response MUST include a Date header field (Section 10.2 of |  | A 304 response MUST include a Date header field (Section 9.10 of |
| [Part2]) unless the origin server does not have a clock that can |  | [Part2]) unless the origin server does not have a clock that can |
| provide a reasonable approximation of the current time. If a 200 |  | provide a reasonable approximation of the current time. If a 200 |
| response to the same request would have included any of the header |  | (OK) response to the same request would have included any of the |
| fields Cache-Control, Content-Location, ETag, Expires, or Vary, then |  | header fields Cache-Control, Content-Location, ETag, Expires, or |
| those same header fields MUST be sent in a 304 response. |  | Vary, then those same header fields MUST be sent in a 304 response. |
| Since the goal of a 304 response is to minimize information transfer |  | Since the goal of a 304 response is to minimize information transfer |
| when the recipient already has one or more cached representations, |  | when the recipient already has one or more cached representations, |
| the response SHOULD NOT include representation metadata other than |  | the response SHOULD NOT include representation metadata other than |
| the above listed fields unless said metadata exists for the purpose |  | the above listed fields unless said metadata exists for the purpose |
| of guiding cache updates (e.g., future HTTP extensions). |  | of guiding cache updates (e.g., future HTTP extensions). |
| If the recipient of a 304 response does not have a cached |  | If the recipient of a 304 response does not have a cached |
| representation corresponding to the entity-tag indicated by the 304 |  | representation corresponding to the entity-tag indicated by the 304 |
| response, then the recipient MUST NOT use the 304 to update its own |  | response, then the recipient MUST NOT use the 304 to update its own |
| cache. If this conditional request originated with an outbound |  | cache. If this conditional request originated with an outbound |
| client, such as a user agent with its own cache sending a conditional |  | client, such as a user agent with its own cache sending a conditional |
| GET to a shared proxy, then the 304 response MAY be forwarded to the |  | GET to a shared proxy, then the 304 response MAY be forwarded to that |
| outbound client. Otherwise, the recipient MUST disregard the 304 |  | client. Otherwise, the recipient MUST disregard the 304 response and |
| response and repeat the request without any preconditions. |  | repeat the request without any preconditions. |
| 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 |  | 4.2. 412 Precondition Failed |
| The 412 status code indicates that one or more preconditions given in |  | The 412 status code indicates that one or more preconditions given in |
| the request header fields evaluated to false when tested on the |  | the request header fields evaluated to false when tested on the |
| server. This response code allows the client to place preconditions |  | server. This response code allows the client to place preconditions |
| on the current resource state (its current representations and |  | on the current resource state (its current representations and |
| metadata) and thus prevent the request method from being applied if |  | metadata) and thus prevent the request method from being applied if |
| the target resource is in an unexpected state. |  | the target resource is in an unexpected state. |
| 5. IANA Considerations |  | 5. Precedence |
| 5.1. Status Code Registration |  | When more than one conditional request header field is present in a |
|  |  | request, the order in which the fields are evaluated becomes |
|  |  | important. In practice, the fields defined in this document are |
|  |  | consistently implemented in a single, logical order, due to the fact |
|  |  | that entity tags are presumed to be more accurate than date |
|  |  | validators. For example, the only reason to send both If-Modified- |
|  |  | Since and If-None-Match in the same GET request is to support |
|  |  | intermediary caches that might not have implemented If-None-Match, so |
|  |  | it makes sense to ignore the If-Modified-Since when entity tags are |
|  |  | understood and available for the selected representation. |
|  |  | The general rule of conditional precedence is that exact match |
|  |  | conditions are evaluated before cache-validating conditions and, |
|  |  | within that order, last-modified conditions are only evaluated if the |
|  |  | corresponding entity tag condition is not present (or not applicable |
|  |  | because the selected representation does not have an entity tag). |
|  |  | Specifically, the fields defined by this specification are evaluated |
|  |  | as follows: |
|  |  | 1. When If-Match is present, evaluate it: |
|  |  | * if true, continue to step 3 |
|  |  | * if false, respond 412 (Precondition Failed) |
|  |  | 2. When If-Match is not present and If-Unmodified-Since is present, |
|  |  | evaluate it: |
|  |  | * if true, continue to step 3 |
|  |  | * if false, respond 412 (Precondition Failed) |
|  |  | 3. When the method is GET and both Range and If-Range are present, |
|  |  | evaluate it: |
|  |  | * if the validator matches, respond 206 (Partial Content) |
|  |  | * if the validator does not match, respond 200 (OK) |
|  |  | 4. When If-None-Match is present, evaluate it: |
|  |  | * if true, all conditions are met |
|  |  | * if false for GET/HEAD, respond 304 (Not Modified) |
|  |  | * if false for other methods, respond 412 (Precondition Failed) |
|  |  | 5. When the method is GET or HEAD, If-None-Match is not present, and |
|  |  | If-Modified-Since is present, evaluate it: |
|  |  | * if true, all conditions are met |
|  |  | * if false, respond 304 (Not Modified) |
|  |  | Any extension to HTTP/1.1 that defines additional conditional request |
|  |  | header fields ought to define its own expectations regarding the |
|  |  | order for evaluating such fields in relation to those defined in this |
|  |  | document and other conditionals that might be found in practice. |
|  |  | 6. IANA Considerations |
|  |  | 6.1. Status Code Registration |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| <http://www.iana.org/assignments/http-status-codes> shall be updated |  | <http://www.iana.org/assignments/http-status-codes> shall be updated |
| with the registrations below: |  | with the registrations below: |
| +-------+---------------------+-------------+ |  | +-------+---------------------+-------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+---------------------+-------------+ |  | +-------+---------------------+-------------+ |
| | 304 | Not Modified | Section 4.1 | |  | | 304 | Not Modified | Section 4.1 | |
| | 412 | Precondition Failed | Section 4.2 | |  | | 412 | Precondition Failed | Section 4.2 | |
| +-------+---------------------+-------------+ |  | +-------+---------------------+-------------+ |
| 5.2. Header Field Registration |  | 6.2. Header Field Registration |
| The Message Header Field Registry located at <http://www.iana.org/ |  | The Message Header Field Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> shall be |  | assignments/message-headers/message-header-index.html> shall 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 2.3 | |  | | ETag | http | standard | Section 2.3 | |
| | If-Match | http | standard | Section 3.1 | |  | | If-Match | http | standard | Section 3.1 | |
| | If-Modified-Since | http | standard | Section 3.3 | |  | | If-Modified-Since | http | standard | Section 3.3 | |
| | If-None-Match | http | standard | Section 3.2 | |  | | If-None-Match | http | standard | Section 3.2 | |
| | 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". |
| 6. Security Considerations |  | 7. 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]. |
| 7. Acknowledgments |  | The validators defined by this specification are not intended to |
|  |  | ensure the validity of a representation, guard against malicious |
|  |  | changes, or detect man-in-the-middle attacks. At best, they enable |
|  |  | more efficient cache updates and optimistic concurrent writes when |
|  |  | all participants are behaving nicely. At worst, the conditions will |
|  |  | fail and the client will receive a response that is no more harmful |
|  |  | than an HTTP exchange without conditional requests. |
| See Section 9 of [Part1]. |  | 8. Acknowledgments |
| 8. References |  | See Section 9 of [Part1]. |
| 8.1. Normative References |  | 9. References |
|  |  | 9.1. Normative References |
| [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 1: URIs, Connections, and Message |  | "HTTP/1.1, part 1: Message Routing and Syntax"", |
| Parsing", draft-ietf-httpbis-p1-messaging-19 (work in |  | draft-ietf-httpbis-p1-messaging-20 (work in progress), |
| progress), March 2012. |  | July 2012. |
| [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 2: Message Semantics", |  | "HTTP/1.1, part 2: Semantics and Payloads", |
| draft-ietf-httpbis-p2-semantics-19 (work in progress), |  | draft-ietf-httpbis-p2-semantics-20 (work in progress), |
| March 2012. |  | July 2012. |
| [Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  |  |
| "HTTP/1.1, part 3: Message Payload and Content |  |  |
| Negotiation", draft-ietf-httpbis-p3-payload-19 (work in |  |  |
| progress), March 2012. |  |  |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 5: Range Requests and Partial Responses", |  | "HTTP/1.1, part 5: Range Requests", |
| draft-ietf-httpbis-p5-range-19 (work in progress), |  | draft-ietf-httpbis-p5-range-20 (work in progress), |
| March 2012. |  | July 2012. |
| [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |  | [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., 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-19 (work in progress), |  | draft-ietf-httpbis-p6-cache-20 (work in progress), |
| March 2012. |  | July 2012. |
| [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. |
| 8.2. Informative References |  | 9.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. |
| [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed |  | [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed |
| skipping to change at page 21, line 34 |  | skipping to change at page 23, line 4 |
| [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed |  | [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed |
| Authoring and Versioning (WebDAV)", RFC 4918, June 2007. |  | Authoring and Versioning (WebDAV)", RFC 4918, June 2007. |
| Appendix A. Changes from RFC 2616 |  | Appendix A. 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 2.1 and 3.2). |  | (Sections 2.1 and 3.2). |
| Change ETag header field ABNF not to use quoted-string, thus avoiding |  | Change ETag header field ABNF not to use quoted-string, thus avoiding |
| escaping issues. (Section 2.3) |  | escaping issues. (Section 2.3) |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 3) |  | value. (Section 3) |
| Appendix B. Collected ABNF |  | Appendix B. Imported ABNF |
|  |  | The following core rules are included by reference, as defined in |
|  |  | Appendix B.1 of [RFC5234]: 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), and VCHAR (any visible US-ASCII |
|  |  | character). |
|  |  | The rules below are defined in [Part1]: |
|  |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
|  |  | obs-text = <obs-text, defined in [Part1], Section 3.2.4> |
|  |  | The rules below are defined in other parts: |
|  |  | HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> |
|  |  | Appendix C. Collected ABNF |
| ETag = entity-tag |  | ETag = entity-tag |
| HTTP-date = <HTTP-date, defined in [Part2], Section 8> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> |
| If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |  | If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
| entity-tag ] ) ) |  | entity-tag ] ) ) |
| If-Modified-Since = HTTP-date |  | If-Modified-Since = HTTP-date |
| If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |  | If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
| entity-tag ] ) ) |  | entity-tag ] ) ) |
| If-Unmodified-Since = HTTP-date |  | If-Unmodified-Since = HTTP-date |
| Last-Modified = HTTP-date |  | Last-Modified = HTTP-date |
| skipping to change at page 22, line 31 |  | skipping to change at page 24, line 5 |
| entity-tag = [ weak ] opaque-tag |  | entity-tag = [ weak ] opaque-tag |
| etagc = "!" / %x23-7E ; '#'-'~' |  | etagc = "!" / %x23-7E ; '#'-'~' |
| / obs-text |  | / obs-text |
| obs-text = <obs-text, defined in [Part1], Section 3.2.4> |  | obs-text = <obs-text, defined in [Part1], Section 3.2.4> |
| opaque-tag = DQUOTE *etagc DQUOTE |  | opaque-tag = DQUOTE *etagc DQUOTE |
| weak = %x57.2F ; W/ |  | weak = %x57.2F ; W/ |
| ABNF diagnostics: |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| ; 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 RFC 2616 |  |  |
| Extracted relevant partitions from [RFC2616]. |  |  |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  |  |
| Informative references" |  |  |
| Other changes: |  |  |
| o Move definitions of 304 and 412 condition codes from Part2. |  |  |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Add explicit references to BNF syntax and rules imported from |  |  |
| other parts of the specification. |  |  |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |  |  |
| non-GET requests" |  |  |
| Ongoing work on IANA Message Header Field Registration |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  |  |
| o Reference RFC 3984, and update header field registrations for |  |  |
| header fields defined in this document. |  |  |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for |  |  |
| ETag matching" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity |  |  |
| value' undefined" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068 |  |  |
| Date header reference" |  |  |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Use "/" instead of "|" for alternatives. |  |  |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  |  |
| whitespace ("OWS") and required whitespace ("RWS"). |  |  |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  |  |
| field 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. |  |  |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/153>: "case- |  |  |
| sensitivity of etag weakness indicator" |  |  |
| C.9. Since draft-ietf-httpbis-p4-conditional-07 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |  |  |
| non-GET requests" (If-Match still was defined to require strong |  |  |
| matching) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |  |  |
| registrations for optional status codes" |  |  |
| C.10. Since draft-ietf-httpbis-p4-conditional-08 |  |  |
| No significant changes. |  |  |
| C.11. Since draft-ietf-httpbis-p4-conditional-09 |  |  |
| No significant changes. |  |  |
| C.12. Since draft-ietf-httpbis-p4-conditional-10 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |  |  |
| 'Requested Variant'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |  |  |
| entity / representation / variant terminology" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  |  |
| removing the 'changes from 2068' sections" |  |  |
| C.13. Since draft-ietf-httpbis-p4-conditional-11 |  |  |
| None. |  |  |
| C.14. Since draft-ietf-httpbis-p4-conditional-12 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |  |  |
| Classification" |  |  |
| C.15. Since draft-ietf-httpbis-p4-conditional-13 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/89>: "If-* and |  |  |
| entities" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/101>: "Definition of |  |  |
| validator weakness" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/269>: "ETags and |  |  |
| Quotes" |  |  |
| C.16. Since draft-ietf-httpbis-p4-conditional-14 |  |  |
| None. |  |  |
| C.17. Since draft-ietf-httpbis-p4-conditional-15 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/304>: "If-Range |  | Changes up to the first Working Group Last Call draft are summarized |
| should be listed when dicussing contexts where L-M can be |  | in <http://tools.ietf.org/html/ |
| considered strong" |  | draft-ietf-httpbis-p4-conditional-19#appendix-C>. |
| C.18. Since draft-ietf-httpbis-p4-conditional-16 |  | D.1. Since draft-ietf-httpbis-p4-conditional-19 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to |
| HTTP's error-handling philosophy" |  | clarify eval order/interaction of conditional headers" |
| C.19. Since draft-ietf-httpbis-p4-conditional-17 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and |
|  |  | Conditional Requests" |
| Closed issues: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |
|  |  | requirements for recipients" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/306>: "does etag |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases" |
| value really use quoted-string" |  |  |
| C.20. Since draft-ietf-httpbis-p4-conditional-18 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional |
|  |  | Request Security Considerations" |
| Closed issues: |  | 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/345>: "Required |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor |
| headers on 304 and 206" |  | conditional header field descriptions" |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 18 |  | 304 Not Modified (status code) 18 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 19 |  | 412 Precondition Failed (status code) 19 |
| E |  | E |
| ETag header field 9 |  | ETag header field 9 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 9 |  | entity-tag 10 |
| ETag 9 |  | ETag 10 |
| etagc 9 |  | etagc 10 |
| If-Match 14 |  | If-Match 14 |
| If-Modified-Since 16 |  | If-Modified-Since 16 |
| If-None-Match 15 |  | If-None-Match 15 |
| If-Unmodified-Since 17 |  | If-Unmodified-Since 17 |
| Last-Modified 7 |  | Last-Modified 7 |
| opaque-tag 9 |  | opaque-tag 10 |
| weak 9 |  | weak 10 |
| H |  | H |
| Header Fields |  | Header Fields |
| ETag 9 |  | ETag 9 |
| If-Match 14 |  | If-Match 14 |
| If-Modified-Since 16 |  | If-Modified-Since 16 |
| If-None-Match 15 |  | If-None-Match 15 |
| If-Unmodified-Since 17 |  | If-Unmodified-Since 17 |
| Last-Modified 7 |  | Last-Modified 7 |
| skipping to change at page 27, line 23 |  | skipping to change at page 25, line 39 |
| metadata 5 |  | metadata 5 |
| S |  | S |
| selected representation 4 |  | selected representation 4 |
| Status Codes |  | Status Codes |
| 304 Not Modified 18 |  | 304 Not Modified 18 |
| 412 Precondition Failed 19 |  | 412 Precondition Failed 19 |
| V |  | V |
| validator 5 |  | validator 5 |
| strong 5 |  | strong 6 |
| weak 5 |  | weak 6 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| skipping to change at page 28, line 4 |  | skipping to change at page 26, line 25 |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| EMail: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| 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 |  |  |
| 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/ |
End of changes. 84 change blocks.
| 398 lines changed or deleted |  | 311 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/