| p4-conditional.unpg.txt |  | rfc7232.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
| Internet-Draft Adobe |  | Request for Comments: 7232 Adobe |
| Obsoletes: 2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2616 J. Reschke, Ed. |
| Intended status: Standards Track greenbytes |  | Category: Standards Track greenbytes |
| Expires: December 8, 2014 June 6, 2014 |  | ISSN: 2070-1721 June 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |  | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
| draft-ietf-httpbis-p4-conditional-latest |  |  |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is a stateless application- |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| level protocol for distributed, collaborative, hypertext information |  | level protocol for distributed, collaborative, hypertext information |
| systems. This document defines HTTP/1.1 conditional requests, |  | systems. This document defines HTTP/1.1 conditional requests, |
| including metadata header fields for indicating state changes, |  | including metadata header fields for indicating state changes, |
| request header fields for making preconditions on such state, and |  | request header fields for making preconditions on such state, and |
| rules for constructing the responses to a conditional request when |  | rules for constructing the responses to a conditional request when |
| one or more preconditions evaluate to false. |  | one or more preconditions evaluate to false. |
| Editorial Note (To be removed by RFC Editor) |  |  |
| Discussion of this draft takes place on the HTTPBIS working group |  |  |
| mailing list (ietf-http-wg@w3.org), which is archived at |  |  |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  |  |
| The current issues list is at |  |  |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  |  |
| documents (including fancy diffs) can be found at |  |  |
| <http://tools.ietf.org/wg/httpbis/>. |  |  |
| _This is a temporary document for the purpose of tracking the |  |  |
| editorial changes made during the AUTH48 (RFC publication) phase._ |  |  |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This is an Internet Standards Track document. |
| provisions of BCP 78 and BCP 79. |  |  |
| Internet-Drafts are working documents of the Internet Engineering |  | This document is a product of the Internet Engineering Task Force |
| Task Force (IETF). Note that other groups may also distribute |  | (IETF). It represents the consensus of the IETF community. It has |
| working documents as Internet-Drafts. The list of current Internet- |  | received public review and has been approved for publication by the |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Internet Engineering Steering Group (IESG). Further information on |
|  |  | Internet Standards is available in Section 2 of RFC 5741. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Information about the current status of this document, any errata, |
| and may be updated, replaced, or obsoleted by other documents at any |  | and how to provide feedback on it may be obtained at |
| time. It is inappropriate to use Internet-Drafts as reference |  | http://www.rfc-editor.org/info/rfc7232. |
| material or to cite them other than as "work in progress." |  |  |
| This Internet-Draft will expire on December 8, 2014. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2014 IETF Trust and the persons identified as the |  | Copyright (c) 2014 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 7 |  | skipping to change at page 3, line 7 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction ....................................................4 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling .............................4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation ............................................4 |
| 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Validators ......................................................5 |
| 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Weak versus Strong .........................................5 |
| 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2. Last-Modified ..............................................7 |
| 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2.1. Generation ..........................................7 |
| 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2.2. Comparison ..........................................8 |
| 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. ETag .......................................................9 |
| 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.3.1. Generation .........................................10 |
| 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.3.2. Comparison .........................................10 |
| 2.3.3. Example: Entity-Tags Varying on Content-Negotiated |  | 2.3.3. Example: Entity-Tags Varying on |
| Resources . . . . . . . . . . . . . . . . . . . . . . 11 |  | Content-Negotiated Resources .......................11 |
| 2.4. When to Use Entity-Tags and Last-Modified Dates . . . . . 12 |  | 2.4. When to Use Entity-Tags and Last-Modified Dates ...........12 |
| 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13 |  | 3. Precondition Header Fields .....................................13 |
| 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 3.1. If-Match ..................................................13 |
| 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.2. If-None-Match .............................................14 |
| 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 |  | 3.3. If-Modified-Since .........................................16 |
| 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |  | 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 . . . . . . . . . . . . . . . . . 18 |  | 4.2. 412 Precondition Failed ...................................19 |
| 5. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 5. Evaluation .....................................................19 |
| 6. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 6. Precedence .....................................................20 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 |  | 7. IANA Considerations ............................................22 |
| 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 21 |  | 7.1. Status Code Registration ..................................22 |
| 7.2. Header Field Registration . . . . . . . . . . . . . . . . 21 |  | 7.2. Header Field Registration .................................22 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 |  | 8. Security Considerations ........................................22 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 9. Acknowledgments ................................................23 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | 10. References ....................................................24 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 |  | 10.1. Normative References .....................................24 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 |  | 10.2. Informative References ...................................24 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 23 |  | Appendix A. Changes from RFC 2616 .................................25 |
| Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 24 |  | Appendix B. Imported ABNF .........................................25 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 24 |  | Appendix C. Collected ABNF ........................................26 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | Index .............................................................27 |
| 1. Introduction |  | 1. Introduction |
| Conditional requests are HTTP requests [RFC7231] that include one or |  | Conditional requests are HTTP requests [RFC7231] that include one or |
| more header fields indicating a precondition to be tested before |  | more header fields indicating a precondition to be tested before |
| applying the method semantics to the target resource. This document |  | applying the method semantics to the target resource. This document |
| defines the HTTP/1.1 conditional request mechanisms in terms of the |  | defines the HTTP/1.1 conditional request mechanisms in terms of the |
| architecture, syntax notation, and conformance criteria defined in |  | architecture, syntax notation, and conformance criteria defined in |
| [RFC7230]. |  | [RFC7230]. |
| Conditional GET requests are the most efficient mechanism for HTTP |  | Conditional GET requests are the most efficient mechanism for HTTP |
| cache updates [RFC7234]. Conditionals can also be applied to state- |  | cache updates [RFC7234]. Conditionals can also be applied to |
| changing methods, such as PUT and DELETE, to prevent the "lost |  | state-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 |
| with its own observable state. The conditional request mechanisms |  | with its own observable state. The conditional request mechanisms |
| assume that the mapping of requests to a "selected representation" |  | assume that the mapping of requests to a "selected representation" |
| (Section 3 of [RFC7231]) will be consistent over time if the server |  | (Section 3 of [RFC7231]) will be consistent over time if the server |
| skipping to change at page 8, line 24 |  | skipping to change at page 8, line 28 |
| o The validator is being compared by an origin server to the actual |  | o The validator is being compared by an origin server to the actual |
| current validator for the representation and, |  | current validator for the representation and, |
| o That origin server reliably knows that the associated |  | o That origin server reliably knows that the associated |
| representation did not change twice during the second covered by |  | representation did not change twice during the second covered by |
| the presented validator. |  | the presented validator. |
| or |  | or |
| o The validator is about to be used by a client in an If-Modified- |  | o The validator is about to be used by a client in an |
| Since, If-Unmodified-Since, or If-Range header field, because the |  | If-Modified-Since, If-Unmodified-Since, or If-Range header field, |
| client has a cache entry for the associated representation, and |  | because the client has a cache entry for the associated |
|  |  | representation, and |
| o That cache entry includes a Date value, which gives the time when |  | o That cache entry includes a Date value, which gives the time when |
| the origin server sent the original response, and |  | the origin server sent the original response, and |
| o The presented Last-Modified time is at least 60 seconds before the |  | o The presented Last-Modified time is at least 60 seconds before the |
| Date value. |  | Date value. |
| or |  | or |
| o The validator is being compared by an intermediate cache to the |  | o The validator is being compared by an intermediate cache to the |
| skipping to change at page 8, line 48 |  | skipping to change at page 9, line 8 |
| o That cache entry includes a Date value, which gives the time when |  | o That cache entry includes a Date value, which gives the time when |
| the origin server sent the original response, and |  | the origin server sent the original response, and |
| o The presented Last-Modified time is at least 60 seconds before the |  | o The presented Last-Modified time is at least 60 seconds before the |
| Date value. |  | Date value. |
| This method relies on the fact that if two different responses were |  | This method relies on the fact that if two different responses were |
| sent by the origin server during the same second, but both had the |  | sent by the origin server during the same second, but both had the |
| 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 |
| second limit guards against the possibility that the Date and Last- |  | 60-second limit guards against the possibility that the Date and |
| Modified values are generated from different clocks or at somewhat |  | Last-Modified values are generated from different clocks or at |
| different times during the preparation of the response. An |  | somewhat 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 in a response provides the current entity-tag |  | The "ETag" header field in a response provides the current entity-tag |
| for the selected representation, as determined at the conclusion of |  | for the selected representation, as determined at the conclusion of |
| handling the request. An entity-tag is an opaque validator for |  | handling the request. 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 |
| skipping to change at page 10, line 37 |  | skipping to change at page 10, line 44 |
| improving service scalability and reliability. |  | improving service scalability and reliability. |
| 2.3.2. Comparison |  | 2.3.2. Comparison |
| There are two entity-tag comparison functions, depending on whether |  | There are two entity-tag comparison functions, depending on whether |
| or not the comparison context allows the use of weak validators: |  | or not the comparison context allows the use of weak validators: |
| o Strong comparison: two entity-tags are equivalent if both are not |  | o Strong comparison: two entity-tags are equivalent if both are not |
| weak and their opaque-tags match character-by-character. |  | weak and their opaque-tags match character-by-character. |
| o Weak comparison: two entity-tags are equivalent if their opaque- |  | o Weak comparison: two entity-tags are equivalent if their |
| tags match character-by-character, regardless of either or both |  | opaque-tags match character-by-character, regardless of either or |
| being tagged as "weak". |  | both being tagged as "weak". |
| The example below shows the results for a set of entity-tag pairs and |  | The example below shows the results for a set of entity-tag pairs and |
| both the weak and strong comparison function results: |  | both the weak and strong comparison function results: |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| | 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 | |
| skipping to change at page 12, line 37 |  | skipping to change at page 13, line 6 |
| send both a strong entity-tag and a Last-Modified value in successful |  | send both a strong entity-tag and a Last-Modified value in successful |
| responses to a retrieval request. |  | responses to a retrieval request. |
| A client: |  | A client: |
| o MUST send that entity-tag in any cache validation request (using |  | o MUST send that entity-tag in any cache validation request (using |
| If-Match or If-None-Match) if an entity-tag has been provided by |  | If-Match or If-None-Match) if an entity-tag has been provided by |
| the origin server. |  | the origin server. |
| o SHOULD send the Last-Modified value in non-subrange cache |  | o SHOULD send the Last-Modified value in non-subrange cache |
| validation requests (using If-Modified-Since) if only a Last- |  | validation requests (using If-Modified-Since) if only a |
| Modified value has been provided by the origin server. |  | Last-Modified value has been provided by the origin server. |
| o MAY send the Last-Modified value in subrange cache validation |  | o MAY send the Last-Modified value in subrange cache validation |
| requests (using If-Unmodified-Since) if only a Last-Modified value |  | requests (using If-Unmodified-Since) if only a Last-Modified value |
| has been provided by an HTTP/1.0 origin server. The user agent |  | has been provided by an HTTP/1.0 origin server. The user agent |
| SHOULD provide a way to disable this, in case of difficulty. |  | SHOULD provide a way to disable this, in case of difficulty. |
| o SHOULD send both validators in cache validation requests if both |  | o SHOULD send both validators in cache validation requests if both |
| an entity-tag and a Last-Modified value have been provided by the |  | an entity-tag and a Last-Modified value have been provided by the |
| origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to |  | origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to |
| respond appropriately. |  | respond appropriately. |
| skipping to change at page 15, line 42 |  | skipping to change at page 16, line 21 |
| data has not changed. |  | data has not changed. |
| 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 |
| A recipient MUST ignore If-Modified-Since if the request contains an |  | A recipient MUST ignore If-Modified-Since if the request contains an |
| If-None-Match header field; the condition in If-None-Match is |  | If-None-Match header field; the condition in If-None-Match is |
| considered to be a more accurate replacement for the condition in If- |  | considered to be a more accurate replacement for the condition in |
| Modified-Since, and the two are only combined for the sake of |  | If-Modified-Since, and the two are only combined for the sake of |
| interoperating with older intermediaries that might not implement If- |  | interoperating with older intermediaries that might not implement |
| None-Match. |  | If-None-Match. |
| A recipient MUST ignore the If-Modified-Since header field if the |  | A recipient MUST ignore the If-Modified-Since header field if the |
| received field-value is not a valid HTTP-date, or if the request |  | received field-value is not a valid HTTP-date, or if the request |
| method is neither GET nor HEAD. |  | method is neither GET nor HEAD. |
| A recipient MUST interpret an If-Modified-Since field-value's |  | A recipient MUST interpret an If-Modified-Since field-value's |
| timestamp in terms of the origin server's clock. |  | timestamp in terms of the origin server's clock. |
| If-Modified-Since is typically used for two distinct purposes: 1) to |  | If-Modified-Since is typically used for two distinct purposes: 1) to |
| allow efficient updates of a cached representation that does not have |  | allow efficient updates of a cached representation that does not have |
| an entity-tag and 2) to limit the scope of a web traversal to |  | an entity-tag and 2) to limit the scope of a web traversal to |
| resources that have recently changed. |  | resources that have recently changed. |
| When used for cache updates, a cache will typically use the value of |  | When used for cache updates, a cache will typically use the value of |
| the cached message's Last-Modified field to generate the field value |  | the cached message's Last-Modified field to generate the field value |
| of If-Modified-Since. This behavior is most interoperable for cases |  | of If-Modified-Since. This behavior is most interoperable for cases |
| where clocks are poorly synchronized or when the server has chosen to |  | where clocks are poorly synchronized or when the server has chosen to |
| only honor exact timestamp matches (due to a problem with Last- |  | only honor exact timestamp matches (due to a problem with |
| Modified dates that appear to go "back in time" when the origin |  | Last-Modified dates that appear to go "back in time" when the origin |
| server's clock is corrected or a representation is restored from an |  | server's clock is corrected or a representation is restored from an |
| archived backup). However, caches occasionally generate the field |  | archived backup). However, caches occasionally generate the field |
| value based on other data, such as the Date header field of the |  | value based on other data, such as the Date header field of the |
| cached message or the local clock time that the message was received, |  | cached message or the local clock time that the message was received, |
| particularly when the cached message does not contain a Last-Modified |  | particularly when the cached message does not contain a Last-Modified |
| field. |  | field. |
| When used for limiting the scope of retrieval to a recent time |  | When used for limiting the scope of retrieval to a recent time |
| window, a user agent will generate an If-Modified-Since field value |  | window, a user agent will generate an If-Modified-Since field value |
| based on either its own local clock or a Date header field received |  | based on either its own local clock or a Date header field received |
| from the server in a prior response. Origin servers that choose an |  | from the server in a prior response. Origin servers that choose an |
| exact timestamp match based on the selected representation's Last- |  | exact timestamp match based on the selected representation's |
| Modified field will not be able to help the user agent limit its data |  | Last-Modified field will not be able to help the user agent limit its |
| transfers to only those changed during the specified window. |  | data transfers to only those changed during the specified window. |
| An origin server that receives an If-Modified-Since header field |  | An origin server that receives an If-Modified-Since header field |
| SHOULD evaluate the condition prior to performing the method |  | SHOULD evaluate the condition prior to performing the method |
| (Section 5). The origin server SHOULD NOT perform the requested |  | (Section 5). The origin server SHOULD NOT perform the requested |
| method if the selected representation's last modification date is |  | method if the selected representation's last modification date is |
| earlier than or equal to the date provided in the field-value; |  | earlier than or equal to the date provided in the field-value; |
| instead, the origin server SHOULD generate a 304 (Not Modified) |  | instead, the origin server SHOULD generate a 304 (Not Modified) |
| response, including only those metadata that are useful for |  | response, including only those metadata that are useful for |
| identifying or updating a previously cached response. |  | identifying or updating a previously cached response. |
| skipping to change at page 17, line 13 |  | skipping to change at page 17, line 41 |
| the user agent does not have an entity-tag for the representation. |  | the user agent does not have an entity-tag for the representation. |
| 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 |
| A recipient MUST ignore If-Unmodified-Since if the request contains |  | A recipient MUST ignore If-Unmodified-Since if the request contains |
| an If-Match header field; the condition in If-Match is considered to |  | an If-Match header field; the condition in If-Match is considered to |
| be a more accurate replacement for the condition in If-Unmodified- |  | be a more accurate replacement for the condition in |
| Since, and the two are only combined for the sake of interoperating |  | If-Unmodified-Since, and the two are only combined for the sake of |
| with older intermediaries that might not implement If-Match. |  | interoperating with older intermediaries that might not implement |
|  |  | If-Match. |
| A recipient MUST ignore the If-Unmodified-Since header field if the |  | A recipient MUST ignore the If-Unmodified-Since header field if the |
| received field-value is not a valid HTTP-date. |  | received field-value is not a valid HTTP-date. |
| A recipient MUST interpret an If-Unmodified-Since field-value's |  | A recipient MUST interpret an If-Unmodified-Since field-value's |
| timestamp in terms of the origin server's clock. |  | timestamp in terms of the origin server's clock. |
| If-Unmodified-Since is most often used with state-changing methods |  | If-Unmodified-Since is most often used with state-changing methods |
| (e.g., POST, PUT, DELETE) to prevent accidental overwrites when |  | (e.g., POST, PUT, DELETE) to prevent accidental overwrites when |
| multiple user agents might be acting in parallel on a resource that |  | multiple user agents might be acting in parallel on a resource that |
| skipping to change at page 23, line 14 |  | skipping to change at page 24, line 17 |
| 10.1. Normative References |  | 10.1. Normative References |
| [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. |
| [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Message Syntax and Routing", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-latest (work in progress), |  | RFC 7230, June 2014. |
| June 2014. |  |  |
| [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Semantics and Content", |  | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, |
| draft-ietf-httpbis-p2-semantics-latest (work in progress), |  |  |
| June 2014. |  | June 2014. |
| [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |  | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
| draft-ietf-httpbis-p5-range-latest (work in progress), |  | RFC 7233, June 2014. |
| June 2014. |  |  |
| [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-latest (work in progress), |  | RFC 7234, June 2014. |
| June 2014. |  |  |
| 10.2. Informative References |  | 10.2. Informative References |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| [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. |
| skipping to change at page 25, line 32 |  | skipping to change at page 27, line 8 |
| / obs-text |  | / obs-text |
| obs-text = <obs-text, see [RFC7230], Section 3.2.6> |  | obs-text = <obs-text, see [RFC7230], Section 3.2.6> |
| opaque-tag = DQUOTE *etagc DQUOTE |  | opaque-tag = DQUOTE *etagc DQUOTE |
| weak = %x57.2F ; W/ |  | weak = %x57.2F ; W/ |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 18 |  | 304 Not Modified (status code) 19 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 18 |  | 412 Precondition Failed (status code) 18 |
| E |  | E |
| ETag header field 9 |  | ETag header field 9 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 9 |  | entity-tag 9 |
| ETag 9 |  | ETag 9 |
| etagc 9 |  | etagc 9 |
| If-Match 13 |  | If-Match 13 |
| If-Modified-Since 15 |  | If-Modified-Since 15 |
| If-None-Match 14 |  | If-None-Match 14 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 17 |
| Last-Modified 7 |  | Last-Modified 7 |
| opaque-tag 9 |  | opaque-tag 9 |
| weak 9 |  | weak 9 |
| I |  | I |
| If-Match header field 13 |  | If-Match header field 13 |
| If-Modified-Since header field 15 |  | If-Modified-Since header field 16 |
| If-None-Match header field 14 |  | If-None-Match header field 14 |
| If-Unmodified-Since header field 16 |  | 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 |
End of changes. 24 change blocks.
| 106 lines changed or deleted |  | 87 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/