| draft-ietf-httpbis-p4-conditional-07.txt |  | draft-ietf-httpbis-p4-conditional-08.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: January 14, 2010 J. Mogul |  | Expires: April 29, 2010 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 13, 2009 |  | October 26, 2009 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-07 |  | draft-ietf-httpbis-p4-conditional-08 |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted to IETF in full conformance with the |
| provisions of BCP 78 and BCP 79. This document may contain material |  | provisions of BCP 78 and BCP 79. This document may contain material |
| from IETF Documents or IETF Contributions published or made publicly |  | from IETF Documents or IETF Contributions published or made publicly |
| available before November 10, 2008. The person(s) controlling the |  | available before November 10, 2008. The person(s) controlling the |
| copyright in some of this material may not have granted the IETF |  | copyright in some of this material may not have granted the IETF |
| Trust the right to allow modifications of such material outside the |  | Trust the right to allow modifications of such material outside the |
| IETF Standards Process. Without obtaining an adequate license from |  | IETF Standards Process. Without obtaining an adequate license from |
| skipping to change at page 2, line 10 |  | skipping to change at page 2, line 10 |
| 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." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on January 14, 2010. |  | This Internet-Draft will expire on April 29, 2010. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2009 IETF Trust and the persons identified as the |  | Copyright (c) 2009 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 in effect on the date of |  | Provisions Relating to IETF Documents in effect on the date of |
| publication of this document (http://trustee.ietf.org/license-info). |  | publication of this document (http://trustee.ietf.org/license-info). |
| Please review these documents carefully, as they describe your rights |  | Please review these documents carefully, as they describe your rights |
| skipping to change at page 2, line 42 |  | skipping to change at page 2, line 42 |
| rules for constructing responses to those requests. |  | rules for constructing responses to those requests. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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.8. |  | The changes in this draft are summarized in Appendix C.9. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2.2. ABNF Rules defined in other Parts of the |  | 1.2.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 5 |  | Specification . . . . . . . . . . . . . . . . . . . . 5 |
| 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| skipping to change at page 3, line 27 |  | skipping to change at page 3, line 27 |
| 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7 |  | 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7 |
| 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |  | 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |
| 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |  | 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |
| 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |  | 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |
| 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |  | 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |
| 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17 |  | 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |
| 7.1. Message Header Registration . . . . . . . . . . . . . . . 17 |  | 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 17 |
|  |  | 7.2. Message Header Registration . . . . . . . . . . . . . . . 18 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 19 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 19 |
| A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 |  | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 20 |  | publication) . . . . . . . . . . . . . . . . . . . . 20 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21 |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21 |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21 |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21 |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22 |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22 |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22 |  | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22 |
|  |  | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 response metadata for indicating |  | This document defines HTTP/1.1 response metadata for indicating |
| potential changes to payload content, including modification time |  | potential changes to payload content, including modification time |
| stamps and opaque entity-tags, and the HTTP conditional request |  | stamps and opaque entity-tags, and the HTTP conditional request |
| mechanisms that allow preconditions to be placed on a request method. |  | mechanisms that allow preconditions to be placed on a request method. |
| Conditional GET requests allow for efficient cache updates. Other |  | Conditional GET requests allow for efficient cache updates. Other |
| skipping to change at page 5, line 19 |  | skipping to change at page 5, line 19 |
| The core rules below are defined in Section 1.2.2 of [Part1]: |  | The core rules below are defined in Section 1.2.2 of [Part1]: |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| 1.2.2. ABNF Rules defined in other Parts of the Specification |  | 1.2.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| 2. Entity Tags |  | 2. Entity Tags |
| Entity tags are used for comparing two or more entities from the same |  | Entity tags are used for comparing two or more entities from the same |
| requested resource. HTTP/1.1 uses entity tags in the ETag |  | requested resource. HTTP/1.1 uses entity tags in the ETag |
| (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4), |  | (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4), |
| and If-Range (Section 5.3 of [Part5]) header fields. The definition |  | and If-Range (Section 5.3 of [Part5]) header fields. The definition |
| of how they are used and compared as cache validators is in |  | of how they are used and compared as cache validators is in |
| Section 4. An entity tag consists of an opaque quoted string, |  | Section 4. An entity tag consists of an opaque quoted string, |
| possibly prefixed by a weakness indicator. |  | possibly prefixed by a weakness indicator. |
| skipping to change at page 6, line 17 |  | skipping to change at page 6, line 17 |
| 3.1. 304 Not Modified |  | 3.1. 304 Not Modified |
| If the client has performed a conditional GET request and access is |  | If the client has performed a conditional GET request and access is |
| allowed, but the document has not been modified, the server SHOULD |  | allowed, but the document has not been modified, the server SHOULD |
| respond with this status code. The 304 response MUST NOT contain a |  | respond with this status code. The 304 response MUST NOT contain a |
| message-body, and thus is always terminated by the first empty line |  | message-body, and thus is always terminated by the first empty line |
| after the header fields. |  | after the header fields. |
| The response MUST include the following header fields: |  | The response MUST include the following header fields: |
| o Date, unless its omission is required by Section 8.3.1 of [Part1]. |  | o Date, unless its omission is required by Section 9.3.1 of [Part1]. |
| If a clockless origin server obeys these rules, and proxies and |  | If a clockless origin server obeys these rules, and proxies and |
| clients add their own Date to any response received without one |  | clients add their own Date to any response received without one |
| (as already specified by Section 8.3 of [Part1], caches will |  | (as already specified by Section 9.3 of [Part1], caches will |
| operate correctly. |  | operate correctly. |
| o ETag and/or Content-Location, if the header would have been sent |  | o ETag and/or Content-Location, if the header would have been sent |
| in a 200 response to the same request. |  | in a 200 response to the same request. |
| o Expires, Cache-Control, and/or Vary, if the field-value might |  | o Expires, Cache-Control, and/or Vary, if the field-value might |
| differ from that sent in any previous response for the same |  | differ from that sent in any previous response for the same |
| variant. |  | variant. |
| If the conditional GET used a strong cache validator (see Section 4), |  | If the conditional GET used a strong cache validator (see Section 4), |
| skipping to change at page 8, line 14 |  | skipping to change at page 8, line 14 |
| The only function that HTTP/1.1 defines on validators is comparison. |  | The only function that HTTP/1.1 defines on validators is comparison. |
| There are two validator comparison functions, depending on whether |  | There are two validator comparison functions, depending on whether |
| the comparison context allows the use of weak validators or not: |  | the comparison context allows the use of weak validators or not: |
| o The strong comparison function: in order to be considered equal, |  | o The strong comparison function: in order to be considered equal, |
| both opaque-tags MUST be identical character-by-character, and |  | both opaque-tags MUST be identical character-by-character, and |
| both MUST NOT be weak. |  | both MUST NOT be weak. |
| o The weak comparison function: in order to be considered equal, |  | o The weak comparison function: in order to be considered equal, |
| both opaque-tags MUST be identical character-by-character. |  | both opaque-tags MUST be identical character-by-character, but |
|  |  | either or both of them MAY be tagged as "weak" without affecting |
|  |  | the result. |
| The example below shows the results for a set of entity tag pairs, |  | The example below shows the results for a set of entity tag pairs, |
| and both the weak and strong comparison function results: |  | and 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 11, line 39 |  | skipping to change at page 11, line 41 |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to conditional requests. |  | fields related to conditional requests. |
| For entity-header fields, both sender and recipient refer to either |  | For entity-header fields, both sender and recipient refer to either |
| the client or the server, depending on who sends and who receives the |  | the client or the server, depending on who sends and who receives the |
| entity. |  | entity. |
| 6.1. ETag |  | 6.1. ETag |
| The response-header field "ETag" provides the current value of the |  | The "ETag" response-header field provides the current value of the |
| entity tag (see Section 2) for the requested variant. The headers |  | entity tag (see Section 2) for the requested variant, which may be |
| used with entity tags are described in Sections 6.2 and 6.4 of this |  | used for comparison with other entities from the same resource (see |
| document, and in Section 5.3 of [Part5]. The entity tag MAY be used |  |  |
| for comparison with other entities from the same resource (see |  |  |
| Section 4). |  | Section 4). |
| ETag = "ETag" ":" OWS ETag-v |  | ETag = "ETag" ":" OWS ETag-v |
| ETag-v = entity-tag |  | ETag-v = entity-tag |
| Examples: |  | Examples: |
| ETag: "xyzzy" |  | ETag: "xyzzy" |
| ETag: W/"xyzzy" |  | ETag: W/"xyzzy" |
| ETag: "" |  | ETag: "" |
| skipping to change at page 12, line 27 |  | skipping to change at page 12, line 27 |
| The principle behind entity tags is that only the service author |  | The principle behind entity tags is that only the service author |
| knows the semantics of a resource well enough to select an |  | knows the semantics of a resource well enough to select an |
| appropriate cache validation mechanism, and the specification of any |  | appropriate cache validation mechanism, and the specification of any |
| validator comparison function more complex than byte-equality would |  | validator comparison function more complex than byte-equality would |
| open up a can of worms. Thus, comparisons of any other headers |  | open up a can of worms. Thus, comparisons of any other headers |
| (except Last-Modified, for compatibility with HTTP/1.0) are never |  | (except Last-Modified, for compatibility with HTTP/1.0) are never |
| used for purposes of validating a cache entry. |  | used for purposes of validating a cache entry. |
| 6.2. If-Match |  | 6.2. If-Match |
| The request-header field "If-Match" is used with a method to make it |  | The "If-Match" request-header field is used to make a request method |
| conditional. A client that has one or more entities previously |  | conditional. A client that has one or more entities previously |
| obtained from the resource can verify that one of those entities is |  | obtained from the resource can verify that one of those entities is |
| current by including a list of their associated entity tags in the |  | current by including a list of their associated entity tags in the |
| If-Match header field. Entity tags are defined in Section 2. The |  | If-Match header field. |
| purpose of this feature is to allow efficient updates of cached |  |  |
| information with a minimum amount of transaction overhead. It is |  | This allows efficient updates of cached information with a minimum |
| also used, on updating requests, to prevent inadvertent modification |  | amount of transaction overhead. It is also used when updating |
| of the wrong version of a resource. As a special case, the value "*" |  | resources, to prevent inadvertent modification of the wrong version |
| matches any current entity of the resource. |  | of a resource. As a special case, the value "*" matches any current |
|  |  | entity of the resource. |
| If-Match = "If-Match" ":" OWS If-Match-v |  | If-Match = "If-Match" ":" OWS If-Match-v |
| If-Match-v = "*" / 1#entity-tag |  | If-Match-v = "*" / 1#entity-tag |
| If any of the entity tags match the entity tag of the entity that |  | If any of the entity tags match the entity tag of the entity that |
| would have been returned in the response to a similar GET request |  | would have been returned in the response to a similar GET request |
| (without the If-Match header) on that resource, or if "*" is given |  | (without the If-Match header) on that resource, or if "*" is given |
| and any current entity exists for that resource, then the server MAY |  | and any current entity exists for that resource, then the server MAY |
| perform the requested method as if the If-Match header field did not |  | perform the requested method as if the If-Match header field did not |
| exist. |  | exist. |
| A server MUST use the strong comparison function (see Section 4) to |  |  |
| compare the entity tags in If-Match. |  |  |
| If none of the entity tags match, or if "*" is given and no current |  | If none of the entity tags match, or if "*" is given and no current |
| entity exists, the server MUST NOT perform the requested method, and |  | entity exists, the server MUST NOT perform the requested method, and |
| MUST return a 412 (Precondition Failed) response. This behavior is |  | MUST return a 412 (Precondition Failed) response. This behavior is |
| most useful when the client wants to prevent an updating method, such |  | most useful when the client wants to prevent an updating method, such |
| as PUT, from modifying a resource that has changed since the client |  | as PUT, from modifying a resource that has changed since the client |
| last retrieved it. |  | last retrieved it. |
| If the request would, without the If-Match header field, result in |  | If the request would, without the If-Match header field, result in |
| anything other than a 2xx or 412 status, then the If-Match header |  | anything other than a 2xx or 412 status, then the If-Match header |
| MUST be ignored. |  | MUST be ignored. |
| skipping to change at page 13, line 38 |  | skipping to change at page 13, line 36 |
| 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 fields is |
| undefined by this specification. |  | undefined by this specification. |
| 6.3. If-Modified-Since |  | 6.3. If-Modified-Since |
| The request-header field "If-Modified-Since" is used with a method to |  | The "If-Modified-Since" request-header field is used to make a |
| make it conditional: if the requested variant has not been modified |  | request method conditional: if the requested variant has not been |
| since the time specified in this field, an entity will not be |  | modified since the time specified in this field, the server will not |
| returned from the server; instead, a 304 (Not Modified) response will |  | return an entity; instead, a 304 (Not Modified) response will be |
| be returned without any message-body. |  | returned. |
| If-Modified-Since = "If-Modified-Since" ":" OWS |  | If-Modified-Since = "If-Modified-Since" ":" OWS |
| If-Modified-Since-v |  | If-Modified-Since-v |
| If-Modified-Since-v = HTTP-date |  | If-Modified-Since-v = 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 GET method with an If-Modified-Since header and no Range header |  | A GET method with an If-Modified-Since header and no Range header |
| requests that the identified entity be transferred only if it has |  | requests that the identified entity be transferred only if it has |
| been modified since the date given by the If-Modified-Since header. |  | been modified since the date given by the If-Modified-Since header. |
| The algorithm for determining this includes the following cases: |  | The algorithm for determining this includes the following cases: |
| 1. If the request would normally result in anything other than a 200 |  | 1. If the request would normally result in anything other than a 200 |
| (OK) status, or if the passed If-Modified-Since date is invalid, |  | (OK) status, or if the passed If-Modified-Since date is invalid, |
| the response is exactly the same as for a normal GET. A date |  | the response is exactly the same as for a normal GET. A date |
| which is later than the server's current time is invalid. |  | which is later than the server's current time is invalid. |
| skipping to change at page 15, line 11 |  | skipping to change at page 15, line 9 |
| to the server's clock. Corrections for different time bases |  | to the server's clock. Corrections for different time bases |
| between client and server are at best approximate due to network |  | between client and server are at best approximate due to network |
| latency. |  | 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 fields is |
| undefined by this specification. |  | undefined by this specification. |
| 6.4. If-None-Match |  | 6.4. If-None-Match |
| The request-header field "If-None-Match" is used with a method to |  | The "If-None-Match" request-header field is used to make a request |
| make it conditional. A client that has one or more entities |  | method conditional. A client that has one or more entities |
| previously obtained from the resource can verify that none of those |  | previously obtained from the resource can verify that none of those |
| entities is current by including a list of their associated entity |  | entities is current by including a list of their associated entity |
| tags in the If-None-Match header field. The purpose of this feature |  | tags in the If-None-Match header field. |
| is to allow efficient updates of cached information with a minimum |  |  |
|  |  | This allows efficient updates of cached information with a minimum |
| amount of transaction overhead. It is also used to prevent a method |  | amount of transaction overhead. It is also used to prevent a method |
| (e.g. PUT) from inadvertently modifying an existing resource when |  | (e.g. PUT) from inadvertently modifying an existing resource when |
| the client believes that the resource does not exist. |  | the client believes that the resource does not exist. |
| As a special case, the value "*" matches any current entity of the |  | As a special case, the value "*" matches any current entity of the |
| resource. |  | resource. |
| If-None-Match = "If-None-Match" ":" OWS If-None-Match-v |  | If-None-Match = "If-None-Match" ":" OWS If-None-Match-v |
| If-None-Match-v = "*" / 1#entity-tag |  | If-None-Match-v = "*" / 1#entity-tag |
| skipping to change at page 15, line 40 |  | skipping to change at page 15, line 39 |
| given and any current entity exists for that resource, then the |  | given and any current entity exists for that resource, then the |
| server MUST NOT perform the requested method, unless required to do |  | server MUST NOT perform the requested method, unless required to do |
| so because the resource's modification date fails to match that |  | so because the resource's modification date fails to match that |
| supplied in an If-Modified-Since header field in the request. |  | supplied in an If-Modified-Since header field in the request. |
| Instead, if the request method was GET or HEAD, the server SHOULD |  | Instead, if the request method was GET or HEAD, the server SHOULD |
| respond with a 304 (Not Modified) response, including the cache- |  | respond with a 304 (Not Modified) response, including the cache- |
| related header fields (particularly ETag) of one of the entities that |  | related header fields (particularly ETag) of one of the entities that |
| matched. For all other request methods, the server MUST respond with |  | matched. For all other request methods, the server MUST respond with |
| a status of 412 (Precondition Failed). |  | a status of 412 (Precondition Failed). |
| See Section 4 for rules on how to determine if two entity tags match. |  |  |
| If none of the entity tags match, then the server MAY perform the |  | If none of the entity tags match, then the server MAY perform the |
| requested method as if the If-None-Match header field did not exist, |  | requested method as if the If-None-Match header field did not exist, |
| but MUST also ignore any If-Modified-Since header field(s) in the |  | but MUST also ignore any If-Modified-Since header field(s) in the |
| request. That is, if no entity tags match, then the server MUST NOT |  | request. That is, if no entity tags match, then the server MUST NOT |
| return a 304 (Not Modified) response. |  | return a 304 (Not Modified) response. |
| If the request would, without the If-None-Match header field, result |  | If the request would, without the If-None-Match header field, result |
| in anything other than a 2xx or 304 status, then the If-None-Match |  | in anything other than a 2xx or 304 status, then the If-None-Match |
| header MUST be ignored. (See Section 5 for a discussion of server |  | header MUST be ignored. (See Section 5 for a discussion of server |
| behavior when both If-Modified-Since and If-None-Match appear in the |  | behavior when both If-Modified-Since and If-None-Match appear in the |
| skipping to change at page 16, line 25 |  | skipping to change at page 16, line 24 |
| 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 fields is |
| undefined by this specification. |  | undefined by this specification. |
| 6.5. If-Unmodified-Since |  | 6.5. If-Unmodified-Since |
| The request-header field "If-Unmodified-Since" is used with a method |  | The "If-Unmodified-Since" request-header field is used to make a |
| to make it conditional. If the requested resource has not been |  | request method conditional. If the requested resource has not been |
| modified since the time specified in this field, the server SHOULD |  | modified since the time specified in this field, the server SHOULD |
| perform the requested operation as if the If-Unmodified-Since header |  | perform the requested operation as if the If-Unmodified-Since header |
| were not present. |  | were not present. |
| If the requested variant has been modified since the specified time, |  | If the requested variant has been modified since the specified time, |
| the server MUST NOT perform the requested operation, and MUST return |  | the server MUST NOT perform the requested operation, and MUST return |
| a 412 (Precondition Failed). |  | a 412 (Precondition Failed). |
| If-Unmodified-Since = "If-Unmodified-Since" ":" OWS |  | If-Unmodified-Since = "If-Unmodified-Since" ":" OWS |
| If-Unmodified-Since-v |  | If-Unmodified-Since-v |
| skipping to change at page 17, line 7 |  | skipping to change at page 17, line 7 |
| If-Unmodified-Since header SHOULD be ignored. |  | If-Unmodified-Since header SHOULD be ignored. |
| If the specified date is invalid, the header is ignored. |  | If the specified date is invalid, the header is 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. |  | fields is undefined by this specification. |
| 6.6. Last-Modified |  | 6.6. Last-Modified |
| The entity-header field "Last-Modified" indicates the date and time |  | The "Last-Modified" entity-header field indicates the date and time |
| at which the origin server believes the variant was last modified. |  | at which the origin server believes the variant was last modified. |
| Last-Modified = "Last-Modified" ":" OWS Last-Modified-v |  | Last-Modified = "Last-Modified" ":" OWS Last-Modified-v |
| Last-Modified-v = HTTP-date |  | Last-Modified-v = HTTP-date |
| An example of its use is |  | An example of its use is |
| Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |  | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| The exact meaning of this header field depends on the implementation |  | The exact meaning of this header field depends on the implementation |
| skipping to change at page 17, line 46 |  | skipping to change at page 17, line 46 |
| near the time that the response is generated. |  | near the time that the response is generated. |
| HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |  | HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |
| The Last-Modified entity-header field value is often used as a cache |  | The Last-Modified entity-header field value is often used as a cache |
| validator. In simple terms, a cache entry is considered to be valid |  | validator. In simple terms, a cache entry is considered to be valid |
| if the entity has not been modified since the Last-Modified value. |  | if the entity has not been modified since the Last-Modified value. |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. Message Header Registration |  | 7.1. Status Code Registration |
|  |  | The HTTP Status Code Registry located at |
|  |  | <http://www.iana.org/assignments/http-status-codes> should be updated |
|  |  | with the registrations below: |
|  |  | +-------+---------------------+-------------+ |
|  |  | | Value | Description | Reference | |
|  |  | +-------+---------------------+-------------+ |
|  |  | | 304 | Not Modified | Section 3.1 | |
|  |  | | 412 | Precondition Failed | Section 3.2 | |
|  |  | +-------+---------------------+-------------+ |
|  |  | 7.2. Message Header Registration |
| The Message Header Registry located at <http://www.iana.org/ |  | The Message Header Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> should be |  | assignments/message-headers/message-header-index.html> should be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [RFC3864]): |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| | ETag | http | standard | Section 6.1 | |  | | ETag | http | standard | Section 6.1 | |
| | If-Match | http | standard | Section 6.2 | |  | | If-Match | http | standard | Section 6.2 | |
| skipping to change at page 18, line 33 |  | skipping to change at page 18, line 46 |
| 9. Acknowledgments |  | 9. Acknowledgments |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-07 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-08 |
| (work in progress), July 2009. |  | (work in progress), October 2009. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-07 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-08 (work |
| in progress), July 2009. |  | in progress), October 2009. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-07 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 10.2. Informative References |  | 10.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| skipping to change at page 20, line 10 |  | skipping to change at page 20, line 10 |
| A.1. Changes from RFC 2616 |  | A.1. 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 4 and 6.4). |  | (Sections 4 and 6.4). |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| ETag = "ETag:" OWS ETag-v |  | ETag = "ETag:" OWS ETag-v |
| ETag-v = entity-tag |  | ETag-v = entity-tag |
| HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| If-Match = "If-Match:" OWS If-Match-v |  | If-Match = "If-Match:" OWS If-Match-v |
| If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |  | If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
| entity-tag ] ) ) |  | entity-tag ] ) ) |
| If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v |  | If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v |
| If-Modified-Since-v = HTTP-date |  | If-Modified-Since-v = HTTP-date |
| If-None-Match = "If-None-Match:" OWS If-None-Match-v |  | If-None-Match = "If-None-Match:" OWS If-None-Match-v |
| If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |  | If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
| entity-tag ] ) ) |  | entity-tag ] ) ) |
| If-Unmodified-Since = "If-Unmodified-Since:" OWS |  | If-Unmodified-Since = "If-Unmodified-Since:" OWS |
| skipping to change at page 22, line 33 |  | skipping to change at page 22, line 33 |
| o Add appendix containing collected and expanded ABNF, reorganize |  | o Add appendix containing collected and expanded ABNF, reorganize |
| ABNF introduction. |  | ABNF introduction. |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 |  | C.8. Since draft-ietf-httpbis-p4-conditional-06 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/153>: "case- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/153>: "case- |
| sensitivity of etag weakness indicator" |  | sensitivity of etag weakness indicator" |
|  |  | C.9. Since draft-ietf-httpbis-p4-conditional-07 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |
|  |  | non-GET requests" (If-Match still was defined to require strong |
|  |  | matching) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |
|  |  | registrations for optional status codes" |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 6 |  | 304 Not Modified (status code) 6 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 6 |  | 412 Precondition Failed (status code) 6 |
| E |  | E |
| ETag header 11 |  | ETag header 11 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 5 |  | entity-tag 5 |
| ETag 11 |  | ETag 11 |
| ETag-v 11 |  | ETag-v 11 |
| If-Match 12 |  | If-Match 12 |
| If-Match-v 12 |  | If-Match-v 12 |
End of changes. 29 change blocks.
| 48 lines changed or deleted |  | 71 lines changed or added |
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/