| draft-ietf-httpbis-p4-conditional-20.txt |  | draft-ietf-httpbis-p4-conditional-21.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) J. Reschke, Ed. |
| Intended status: Standards Track W3C |  | Intended status: Standards Track greenbytes |
| Expires: January 17, 2013 J. Reschke, Ed. |  | Expires: April 7, 2013 October 4, 2012 |
| greenbytes |  |  |
| July 16, 2012 |  |  |
| HTTP/1.1, part 4: Conditional Requests |  | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
| draft-ietf-httpbis-p4-conditional-20 |  | draft-ietf-httpbis-p4-conditional-21 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. This document defines HTTP/1.1 conditional requests, |  | systems. This document defines HTTP/1.1 conditional requests, |
| including metadata header fields for indicating state changes, |  | including metadata header fields for indicating state changes, |
| request header fields for making preconditions on such state, and |  | request header fields for making preconditions on such state, and |
| rules for constructing the responses to a conditional request when |  | rules for constructing the responses to a conditional request when |
| one or more preconditions evaluate to false. |  | one or more preconditions evaluate to false. |
| skipping to change at page 1, line 35 |  | skipping to change at page 1, line 33 |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.1. |  | The changes in this draft are summarized in Appendix D.2. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
|  |  | This Internet-Draft will expire on April 7, 2013. |
| 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 3, line 11 |  | 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 . . . . . . . . . . . . . . . . . . . . 6 |  | 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5 |
| 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.3.3. Example: Entity-tags varying on Content-Negotiated |  | 2.3.3. Example: Entity-tags varying on Content-Negotiated |
| Resources . . . . . . . . . . . . . . . . . . . . . . 11 |  | Resources . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.4. 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 . . . . . . . . . . . . . . . . . . 13 |
| 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |  | 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 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 . . . . . . . . . . . . . . . . . 18 |
| 5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 |
| 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 |  | 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 |
| 6.2. Header Field Registration . . . . . . . . . . . . . . . . 21 |  | 6.2. Header Field Registration . . . . . . . . . . . . . . . . 20 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 |
| Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 23 |  | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 22 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 23 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 23 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 24 |  | publication) . . . . . . . . . . . . . . . . . . . . 23 |
| D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 24 |  | D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 23 |
|  |  | D.2. Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 24 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 1. Introduction |  | 1. Introduction |
| Conditional requests are HTTP requests [Part2] that include one or |  | Conditional requests are HTTP requests [Part2] that include one or |
| more header fields indicating a precondition to be tested before |  | more header fields indicating a precondition to be tested before |
| applying the method semantics to the target resource. Each |  | applying the method semantics to the target resource. Each |
| precondition is based on metadata that is expected to change if the |  | precondition is based on metadata that is expected to change if the |
| selected representation of the target resource is changed. This |  | selected representation of the target resource is changed. This |
| document defines the HTTP/1.1 conditional request mechanisms in terms |  | document defines the HTTP/1.1 conditional request mechanisms in terms |
| skipping to change at page 4, line 47 |  | 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 specification targets conformance criteria according to the role |  | Conformance criteria and considerations regarding error handling are |
| of a participant in HTTP communication. Hence, HTTP requirements are |  | defined in Section 2.5 of [Part1]. |
| placed on senders, recipients, clients, servers, user agents, |  |  |
| 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 |  |  |
| the requirements associated with the roles it partakes in HTTP. Note |  |  |
| that SHOULD-level requirements are relevant here, unless one of the |  |  |
| documented exceptions is applicable. |  |  |
| This document also uses ABNF to define valid protocol elements |  |  |
| (Section 1.2). In addition to the prose requirements placed upon |  |  |
| 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, a recipient MAY attempt to recover a usable |  |  |
| protocol element from an invalid construct. HTTP does not define |  |  |
| specific error handling mechanisms except when they have a direct |  |  |
| impact on security, since different applications of the protocol |  |  |
| require different error handling strategies. For example, a Web |  |  |
| browser might wish to transparently recover from a response where the |  |  |
| Location header field doesn't parse according to the ABNF, whereas a |  |  |
| systems control client might consider any form of error recovery to |  |  |
| 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 describes rules imported from other |  | 1.2 of [Part1]. Appendix B describes rules imported from other |
| documents. Appendix C shows the collected ABNF with the list rule |  | documents. Appendix C shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| 2. Validators |  | 2. Validators |
| skipping to change at page 11, line 41 |  | skipping to change at page 11, line 16 |
| | 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 8 |  | Consider a resource that is subject to content negotiation (Section |
| of [Part2]), and where the representations returned upon a GET |  | 3.4 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 9.3 of [Part2]): |  | (Section 6.3.4 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 18, line 38 |  | skipping to change at page 18, line 20 |
| 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.10 of |  | A 304 response MUST include a Date header field (Section 8.1.1.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 |
| (OK) response to the same request would have included any of the |  | (OK) response to the same request would have included any of the |
| header fields Cache-Control, Content-Location, ETag, Expires, or |  | header fields Cache-Control, Content-Location, ETag, Expires, or |
| Vary, then 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 |
| skipping to change at page 22, line 4 |  | skipping to change at page 21, line 25 |
| more efficient cache updates and optimistic concurrent writes when |  | more efficient cache updates and optimistic concurrent writes when |
| all participants are behaving nicely. At worst, the conditions will |  | all participants are behaving nicely. At worst, the conditions will |
| fail and the client will receive a response that is no more harmful |  | fail and the client will receive a response that is no more harmful |
| than an HTTP exchange without conditional requests. |  | than an HTTP exchange without conditional requests. |
| 8. Acknowledgments |  | 8. Acknowledgments |
| See Section 9 of [Part1]. |  | See Section 9 of [Part1]. |
| 9. References |  | 9. References |
| 9.1. Normative References |  | 9.1. Normative References |
| [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 1: Message Routing and Syntax"", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-20 (work in progress), |  | draft-ietf-httpbis-p1-messaging-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 2: Semantics and Payloads", |  | Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-20 (work in progress), |  | draft-ietf-httpbis-p2-semantics-21 (work in progress), |
| July 2012. |  | October 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", |  | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
| draft-ietf-httpbis-p5-range-20 (work in progress), |  | draft-ietf-httpbis-p5-range-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-20 (work in progress), |  | draft-ietf-httpbis-p6-cache-21 (work in progress), |
| July 2012. |  | October 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. |
| 9.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., |
| skipping to change at page 22, line 50 |  | skipping to change at page 22, line 24 |
| September 2004. |  | September 2004. |
| [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 |
| escaping issues. (Section 2.3) |  | avoiding escaping issues. (Section 2.3) |
| Change ABNF productions for header fields to only define the field |  |  |
| value. (Section 3) |  |  |
| Appendix B. Imported ABNF |  | Appendix B. Imported ABNF |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
| CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |  | 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 |  | 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 |  | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| character). |  | character). |
| The rules below are defined in [Part1]: |  | The rules below are defined in [Part1]: |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| obs-text = <obs-text, defined in [Part1], Section 3.2.4> |  | obs-text = <obs-text, defined in [Part1], Section 3.2.4> |
| The rules below are defined in other parts: |  | The rules below are defined in other parts: |
| HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> |
| Appendix C. Collected ABNF |  | Appendix C. Collected ABNF |
| ETag = entity-tag |  | ETag = entity-tag |
| HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.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 24, line 18 |  | skipping to change at page 23, line 44 |
| in <http://tools.ietf.org/html/ |  | in <http://tools.ietf.org/html/ |
| draft-ietf-httpbis-p4-conditional-19#appendix-C>. |  | draft-ietf-httpbis-p4-conditional-19#appendix-C>. |
| D.1. Since draft-ietf-httpbis-p4-conditional-19 |  | D.1. Since draft-ietf-httpbis-p4-conditional-19 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to |
| clarify eval order/interaction of conditional headers" |  | clarify eval order/interaction of conditional headers" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required |
|  |  | headers on 304 and 206" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality |
|  |  | of Conditional Request Support" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and |
| Conditional Requests" |  | Conditional Requests" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |
| requirements for recipients" |  | requirements for recipients" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional |
| Request Security Considerations" |  | Request Security Considerations" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified- |
| Since lacks definition for method != GET" |  | Since lacks definition for method != GET" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor |
| conditional header field descriptions" |  | conditional header field descriptions" |
|  |  | D.2. Since draft-ietf-httpbis-p4-conditional-20 |
|  |  | o Conformance criteria and considerations regarding error handling |
|  |  | are now defined in Part 1. |
| 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) 18 |
| E |  | E |
| ETag header field 9 |  | ETag header field 9 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 10 |  | entity-tag 9 |
| ETag 10 |  |  |
| etagc 10 |  |  |
| If-Match 14 |  |  |
| If-Modified-Since 16 |  |  |
| If-None-Match 15 |  |  |
| If-Unmodified-Since 17 |  |  |
| Last-Modified 7 |  |  |
| opaque-tag 10 |  |  |
| weak 10 |  |  |
| H |  |  |
| Header Fields |  |  |
| ETag 9 |  | ETag 9 |
|  |  | etagc 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 |
|  |  | opaque-tag 9 |
|  |  | weak 9 |
| I |  | I |
| If-Match header field 14 |  | If-Match header field 13 |
| If-Modified-Since header field 16 |  | If-Modified-Since header field 16 |
| If-None-Match header field 15 |  | If-None-Match header field 14 |
| If-Unmodified-Since header field 17 |  | If-Unmodified-Since header field 17 |
| L |  | L |
| Last-Modified header field 7 |  | Last-Modified header field 7 |
| M |  | M |
| metadata 5 |  | metadata 5 |
| S |  | S |
| selected representation 4 |  | selected representation 4 |
| Status Codes |  |  |
| 304 Not Modified 18 |  |  |
| 412 Precondition Failed 19 |  |  |
| V |  | V |
| validator 5 |  | 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/ |
| Yves Lafon (editor) |  |  |
| World Wide Web Consortium |  |  |
| W3C / ERCIM |  |  |
| 2004, rte des Lucioles |  |  |
| Sophia-Antipolis, AM 06902 |  |  |
| France |  |  |
| EMail: ylafon@w3.org |  |  |
| 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 |
| 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. 37 change blocks.
| 114 lines changed or deleted |  | 68 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/