| draft-ietf-httpbis-p4-conditional-18.txt |  | draft-ietf-httpbis-p4-conditional-19.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) Y. Lafon, Ed. |
| Intended status: Standards Track Alcatel-Lucent |  | Intended status: Standards Track W3C |
| Expires: July 7, 2012 J. Mogul |  | Expires: September 13, 2012 J. Reschke, Ed. |
| HP |  |  |
| H. Frystyk |  |  |
| Microsoft |  |  |
| L. Masinter |  |  |
| Adobe |  |  |
| P. Leach |  |  |
| Microsoft |  |  |
| T. Berners-Lee |  |  |
| W3C/MIT |  |  |
| Y. Lafon, Ed. |  |  |
| W3C |  |  |
| J. Reschke, Ed. |  |  |
| greenbytes |  | greenbytes |
| January 4, 2012 |  | March 12, 2012 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-18 |  | draft-ietf-httpbis-p4-conditional-19 |
| 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. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 4 of the |  | information initiative since 1990. This document is Part 4 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 37 |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org), which is archived at |  | group 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.19. |  | The changes in this draft are summarized in Appendix C.20. |
| 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 July 7, 2012. |  | This Internet-Draft will expire on September 13, 2012. |
| 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 51 |  | skipping to change at page 2, line 39 |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |
| 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6 |  | 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5 |
| 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 12 |  | 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 . . . . . . . . . . . . . . . . . . . . . . 12 |  | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 15 |  | 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |
| 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16 |  | 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |
| 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 17 |  | 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 |
| 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 |  | 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |
| 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 19 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 |
| 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 20 |  | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 |
| 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 |  | 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |
| 5.2. Header Field Registration . . . . . . . . . . . . . . . . 20 |  | 5.2. Header Field Registration . . . . . . . . . . . . . . . . 19 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 23 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 23 |  | publication) . . . . . . . . . . . . . . . . . . . . 22 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 24 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 24 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 24 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 25 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 25 |  | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 |
| C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 25 |  | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 |
| C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 25 |  | C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 |
| C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 25 |  | C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 |
| C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 |  | C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 |
| C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 26 |  | C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 |
| C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 26 |  | C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 |
| C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 26 |  | C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25 |
| C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 26 |  | C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 25 |
| C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 26 |  | C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 25 |
| C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 26 |  | C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 25 |
| C.19. Since draft-ietf-httpbis-p4-conditional-17 . . . . . . . . 27 |  | C.19. Since draft-ietf-httpbis-p4-conditional-17 . . . . . . . . 26 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 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, |  | This document defines the HTTP/1.1 conditional request mechanisms, |
| including both metadata for indicating/observing changes in resource |  | including both metadata for indicating/observing changes in resource |
| representations and request header fields that specify preconditions |  | representations and request header fields that specify preconditions |
| on that metadata be checked before performing the request method. |  | on that metadata be checked before performing the request method. |
| 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 |
| skipping to change at page 6, line 19 |  | skipping to change at page 5, line 19 |
| define specific error handling mechanisms, except in cases where it |  | define specific error handling mechanisms, except in cases where it |
| has direct impact on security. This is because different uses of the |  | has direct impact on security. This is because different uses of the |
| protocol require different error handling strategies; for example, a |  | protocol require different error handling strategies; for example, a |
| Web browser may wish to transparently recover from a response where |  | Web browser may wish to transparently recover from a response where |
| the Location header field doesn't parse according to the ABNF, |  | the Location header field doesn't parse according to the ABNF, |
| whereby in a systems control protocol using HTTP, this type of error |  | whereby in a systems control protocol using HTTP, this type of error |
| recovery could lead to dangerous consequences. |  | recovery could lead to dangerous consequences. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 1.2 of |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| [Part1] (which extends the syntax defined in [RFC5234] with a list |  | notation of [RFC5234] with the list rule extension defined in Section |
| rule). Appendix B shows the collected ABNF, with the list rule |  | 1.2 of [Part1]. Appendix B shows the collected ABNF with the list |
| expanded. |  | rule expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (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 |  | 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 |  | sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| character). |  | character). |
| The ABNF rules below are defined in [Part1] and [Part2]: |  | The ABNF rules below are defined in [Part1] and [Part2]: |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| obs-text = <obs-text, defined in [Part1], Section 3.2.3> |  | obs-text = <obs-text, defined in [Part1], Section 3.2.4> |
| HTTP-date = <HTTP-date, defined in [Part2], Section 8> |  | 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 and opaque entity tags. Additional metadata that |
| reflects resource state has been defined by various extensions of |  | reflects resource state has been defined by various extensions of |
| HTTP, such as WebDAV [RFC4918], that are beyond the scope of this |  | HTTP, such as WebDAV [RFC4918], that are beyond the scope of this |
| specification. A resource metadata value is referred to as a |  | specification. A resource metadata value is referred to as a |
| skipping to change at page 13, line 39 |  | skipping to change at page 12, line 39 |
| 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 must 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 5.1 of [Part1]) apply only during message |  | codings (Section 4 of [Part1]) apply only during message transfer |
| 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. |
| HTTP/1.1 origin servers: |  | HTTP/1.1 origin servers: |
| o SHOULD send an entity-tag validator unless it is not feasible to |  | o SHOULD send an entity-tag validator unless it is not feasible to |
| skipping to change at page 16, line 6 |  | skipping to change at page 15, line 6 |
| anything other than a 2xx or 412 status code, then the If-Match |  | anything other than a 2xx or 412 status code, then the If-Match |
| header field MUST be ignored. |  | 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 |  | The result of a request having both an If-Match header field and |
| either an If-None-Match or an If-Modified-Since header fields is |  | either an If-None-Match or an If-Modified-Since header field is |
| undefined by this specification. |  | 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 MAY 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. If-None-Match is primarily |
| used in conditional GET requests to enable efficient updates of |  | used in conditional GET requests to enable efficient updates of |
| cached information with a minimum amount of transaction overhead. A |  | cached information with a minimum amount of transaction overhead. A |
| client that has one or more representations previously obtained from |  | client that has one or more representations previously obtained from |
| skipping to change at page 17, line 15 |  | skipping to change at page 16, line 15 |
| Examples: |  | Examples: |
| If-None-Match: "xyzzy" |  | If-None-Match: "xyzzy" |
| If-None-Match: W/"xyzzy" |  | If-None-Match: W/"xyzzy" |
| If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |  | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
| If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |  | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
| If-None-Match: * |  | If-None-Match: * |
| The result of a request having both an If-None-Match header field and |  | The result of a request having both an If-None-Match header field and |
| either an If-Match or an If-Unmodified-Since header fields is |  | either an If-Match or an If-Unmodified-Since header field is |
| undefined by this specification. |  | 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 MAY be used to make a request |
| method conditional by modification date: if the selected |  | 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. |
| skipping to change at page 18, line 35 |  | skipping to change at page 17, line 35 |
| 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 |  | The result of a request having both an If-Modified-Since header field |
| and either an If-Match or an If-Unmodified-Since header fields is |  | and either an If-Match or an If-Unmodified-Since header field is |
| undefined by this specification. |  | 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 MAY 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 |
| skipping to change at page 19, line 15 |  | skipping to change at page 18, line 15 |
| 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 the request normally (i.e., without the If-Unmodified-Since header |
| field) would result in anything other than a 2xx or 412 status code, |  | field) would result in anything other than a 2xx or 412 status code, |
| the If-Unmodified-Since header field SHOULD be ignored. |  | 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 |  | The result of a request having both an If-Unmodified-Since header |
| field and either an If-None-Match or an If-Modified-Since header |  | field and either an If-None-Match or an If-Modified-Since header |
| fields is undefined by this specification. |  | 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 |
| skipping to change at page 19, line 39 |  | skipping to change at page 18, line 39 |
| 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 9.2 of |  | A 304 response MUST include a Date header field (Section 10.2 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 |  | response to the same request would have included any of the header |
| fields Cache-Control, Content-Location, ETag, Expires, Last-Modified, |  | fields Cache-Control, Content-Location, ETag, Expires, or Vary, then |
| or Vary, then those same header fields MUST be sent in a 304 |  | those same header fields MUST be sent in a 304 response. |
| 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 |
| skipping to change at page 21, line 26 |  | skipping to change at page 20, line 26 |
| 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 |  | 6. 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 |  | 7. Acknowledgments |
| See Section 11 of [Part1]. |  | See Section 9 of [Part1]. |
| 8. References |  | 8. References |
| 8.1. Normative References |  | 8.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 1: URIs, Connections, and Message |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | Parsing", draft-ietf-httpbis-p1-messaging-19 (work in |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-18 |  | progress), March 2012. |
| (work in progress), January 2012. |  |  |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 2: Message Semantics", |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | draft-ietf-httpbis-p2-semantics-19 (work in progress), |
| Semantics", draft-ietf-httpbis-p2-semantics-18 (work in |  | March 2012. |
| progress), January 2012. |  |  |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 3: Message Payload and Content |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | Negotiation", draft-ietf-httpbis-p3-payload-19 (work in |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-18 |  | progress), March 2012. |
| (work in progress), January 2012. |  |  |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | "HTTP/1.1, part 5: Range Requests and Partial Responses", |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | draft-ietf-httpbis-p5-range-19 (work in progress), |
| Partial Responses", draft-ietf-httpbis-p5-range-18 (work |  | March 2012. |
| in progress), January 2012. |  |  |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | draft-ietf-httpbis-p6-cache-19 (work in progress), |
| 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in |  | March 2012. |
| progress), January 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 |  | 8.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| skipping to change at page 23, line 20 |  | skipping to change at page 22, line 20 |
| 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 |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| 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.3> |  | 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: |  | ABNF diagnostics: |
| ; ETag defined but not used |  | ; ETag defined but not used |
| ; If-Match defined but not used |  | ; If-Match defined but not used |
| ; If-Modified-Since defined but not used |  | ; If-Modified-Since defined but not used |
| ; If-None-Match defined but not used |  | ; If-None-Match defined but not used |
| skipping to change at page 27, line 12 |  | skipping to change at page 26, line 12 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
| HTTP's error-handling philosophy" |  | HTTP's error-handling philosophy" |
| C.19. Since draft-ietf-httpbis-p4-conditional-17 |  | C.19. Since draft-ietf-httpbis-p4-conditional-17 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/306>: "does etag |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/306>: "does etag |
| value really use quoted-string" |  | value really use quoted-string" |
|  |  | C.20. Since draft-ietf-httpbis-p4-conditional-18 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required |
|  |  | headers on 304 and 206" |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 19 |  | 304 Not Modified (status code) 18 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 20 |  | 412 Precondition Failed (status code) 19 |
| E |  | E |
| ETag header field 10 |  | ETag header field 9 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 10 |  | entity-tag 9 |
| ETag 10 |  | ETag 9 |
| etagc 10 |  | etagc 9 |
| If-Match 15 |  | If-Match 14 |
| If-Modified-Since 17 |  | If-Modified-Since 16 |
| If-None-Match 16 |  | If-None-Match 15 |
| If-Unmodified-Since 18 |  | If-Unmodified-Since 17 |
| Last-Modified 8 |  | Last-Modified 7 |
| opaque-tag 10 |  | opaque-tag 9 |
| weak 10 |  | weak 9 |
| H |  | H |
| Header Fields |  | Header Fields |
| ETag 10 |  | ETag 9 |
| If-Match 15 |  | If-Match 14 |
| If-Modified-Since 17 |  | If-Modified-Since 16 |
| If-None-Match 16 |  | If-None-Match 15 |
| If-Unmodified-Since 18 |  | If-Unmodified-Since 17 |
| Last-Modified 8 |  | Last-Modified 7 |
| I |  | I |
| If-Match header field 15 |  | If-Match header field 14 |
| If-Modified-Since header field 17 |  | If-Modified-Since header field 16 |
| If-None-Match header field 16 |  | If-None-Match header field 15 |
| If-Unmodified-Since header field 18 |  | If-Unmodified-Since header field 17 |
| L |  | L |
| Last-Modified header field 8 |  | Last-Modified header field 7 |
| M |  | M |
| metadata 6 |  | metadata 5 |
| S |  | S |
| selected representation 5 |  | selected representation 4 |
| Status Codes |  | Status Codes |
| 304 Not Modified 19 |  | 304 Not Modified 18 |
| 412 Precondition Failed 20 |  | 412 Precondition Failed 19 |
| V |  | V |
| validator 6 |  | validator 5 |
| strong 6 |  | strong 5 |
| weak 6 |  | weak 5 |
| 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 |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  |  |
| Alcatel-Lucent Bell Labs |  |  |
| 21 Oak Knoll Road |  |  |
| Carlisle, MA 01741 |  |  |
| USA |  |  |
| EMail: jg@freedesktop.org |  |  |
| URI: http://gettys.wordpress.com/ |  |  |
| Jeffrey C. Mogul |  |  |
| Hewlett-Packard Company |  |  |
| HP Labs, Large Scale Systems Group |  |  |
| 1501 Page Mill Road, MS 1177 |  |  |
| Palo Alto, CA 94304 |  |  |
| USA |  |  |
| EMail: JeffMogul@acm.org |  |  |
| Henrik Frystyk Nielsen |  |  |
| Microsoft Corporation |  |  |
| 1 Microsoft Way |  |  |
| Redmond, WA 98052 |  |  |
| USA |  |  |
| EMail: henrikn@microsoft.com |  |  |
| Larry Masinter |  |  |
| Adobe Systems Incorporated |  |  |
| 345 Park Ave |  |  |
| San Jose, CA 95110 |  |  |
| USA |  |  |
| EMail: LMM@acm.org |  |  |
| URI: http://larry.masinter.net/ |  |  |
| Paul J. Leach |  |  |
| Microsoft Corporation |  |  |
| 1 Microsoft Way |  |  |
| Redmond, WA 98052 |  |  |
| EMail: paulle@microsoft.com |  |  |
| Tim Berners-Lee |  |  |
| World Wide Web Consortium |  |  |
| MIT Computer Science and Artificial Intelligence Laboratory |  |  |
| The Stata Center, Building 32 |  |  |
| 32 Vassar Street |  |  |
| Cambridge, MA 02139 |  |  |
| USA |  |  |
| EMail: timbl@w3.org |  |  |
| URI: http://www.w3.org/People/Berners-Lee/ |  |  |
| 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 |  | Phone: +49 251 2807760 |
| Fax: +49 251 2807761 |  | Fax: +49 251 2807761 |
| EMail: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 40 change blocks.
| 199 lines changed or deleted |  | 138 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/