| draft-ietf-httpbis-p4-conditional-11.txt |  | draft-ietf-httpbis-p4-conditional-12.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 Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: February 5, 2011 J. Mogul |  | Expires: April 28, 2011 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 |
| August 4, 2010 |  | October 25, 2010 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-11 |  | draft-ietf-httpbis-p4-conditional-12 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 4 of the |  | information initiative since 1990. This document is Part 4 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |
| request header fields for indicating conditional requests and the |  | request header fields for indicating conditional requests and the |
| 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/3> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.12. |  | The changes in this draft are summarized in Appendix C.13. |
| 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 February 5, 2011. |  | This Internet-Draft will expire on April 28, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |
| 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 . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2.1. Example: Entity-tags varying on Content-Negotiated |  | 2.1. Example: Entity-tags varying on Content-Negotiated |
| Resources . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | Resources . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 8 |
| 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7 |  | 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 8 |
| 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 7 |  | 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8 |
| 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8 |  | 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 9 |
| 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 10 |  | 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 11 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 13 |
| 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14 |  | 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 |
| 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16 |  | 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 17 |
| 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |  | 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 |
| 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18 |  | 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 19 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 |
| 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |  | 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 |
| 7.2. Header Field Registration . . . . . . . . . . . . . . . . 19 |  | 7.2. Header Field Registration . . . . . . . . . . . . . . . . 20 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 21 |  | publication) . . . . . . . . . . . . . . . . . . . . 22 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23 |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24 |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23 |  | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 |
| C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23 |  | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 |
| C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23 |  | C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 |
| C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23 |  | C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 |
| C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 |  | C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 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 |
| conditional request methods are used to protect against overwriting |  | conditional request methods are used to protect against overwriting |
| or misunderstanding the state of a resource that has been changed |  | or misunderstanding the state of a resource that has been changed |
| unbeknownst to the requesting client. |  | unbeknownst to the requesting client. |
| This document is currently disorganized in order to minimize the |  | This document is currently disorganized in order to minimize the |
| changes between drafts and enable reviewers to see the smaller errata |  | changes between drafts and enable reviewers to see the smaller errata |
| changes. The next draft will reorganize the sections to better |  | changes. A future draft will reorganize the sections to better |
| reflect the content. In particular, the sections on resource |  | reflect the content. In particular, the sections on resource |
| metadata will be discussed first and then followed by each |  | metadata will be discussed first and then followed by each |
| conditional request-header, concluding with a definition of |  | conditional request-header field, concluding with a definition of |
| precedence and the expectation of ordering strong validator checks |  | precedence and the expectation of ordering strong validator checks |
| before weak validator checks. It is likely that more content from |  | before weak validator checks. It is likely that more content from |
| [Part6] will migrate to this part, where appropriate. The current |  | [Part6] will migrate to this part, where appropriate. The current |
| mess reflects how widely dispersed these topics and associated |  | mess reflects how widely dispersed these topics and associated |
| requirements had become in [RFC2616]. |  | requirements had become in [RFC2616]. |
| 1.1. Requirements |  | 1.1. Requirements |
| 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 |
| skipping to change at page 10, line 5 |  | skipping to change at page 11, line 5 |
| 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 If-Modified- |
| Since or If-Unmodified-Since header, because the client has a |  | Since or If-Unmodified-Since header field, because the client has |
| cache entry for the associated representation, and |  | 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 11, line 17 |  | skipping to change at page 12, line 17 |
| o SHOULD send an entity-tag validator unless it is not feasible to |  | o SHOULD send an entity-tag validator unless it is not feasible to |
| generate one. |  | generate one. |
| o MAY send a weak entity-tag instead of a strong entity-tag, if |  | o MAY send a weak entity-tag instead of a strong entity-tag, if |
| performance considerations support the use of weak entity-tags, or |  | performance considerations support the use of weak entity-tags, or |
| if it is unfeasible to send a strong entity-tag. |  | if it is unfeasible to send a strong entity-tag. |
| o SHOULD send a Last-Modified value if it is feasible to send one, |  | o SHOULD send a Last-Modified value if it is feasible to send one, |
| unless the risk of a breakdown in semantic transparency that could |  | unless the risk of a breakdown in semantic transparency that could |
| result from using this date in an If-Modified-Since header would |  | result from using this date in an If-Modified-Since header field |
| lead to serious problems. |  | would lead to serious problems. |
| In other words, the preferred behavior for an HTTP/1.1 origin server |  | In other words, the preferred behavior for an HTTP/1.1 origin server |
| is to send both a strong entity-tag and a Last-Modified value. |  | is to send both a strong entity-tag and a Last-Modified value. |
| In order to be legal, a strong entity-tag MUST change whenever the |  | In order to be legal, a strong entity-tag MUST change whenever the |
| associated representation changes in any way. A weak entity-tag |  | associated representation changes in any way. A weak entity-tag |
| SHOULD change whenever the associated representation changes in a |  | SHOULD change whenever the associated representation changes in a |
| semantically significant way. |  | semantically significant way. |
| Note: In order to provide semantically transparent caching, an |  | Note: In order to provide semantically transparent caching, an |
| skipping to change at page 13, line 23 |  | skipping to change at page 14, line 23 |
| more reliable validation than modification dates in situations where |  | more reliable validation than modification dates in situations where |
| it is inconvenient to store modification dates, where the one-second |  | it is inconvenient to store modification dates, where the one-second |
| resolution of HTTP date values is not sufficient, or where the origin |  | resolution of HTTP date values is not sufficient, or where the origin |
| server wishes to avoid certain paradoxes that might arise from the |  | server wishes to avoid certain paradoxes that might arise from the |
| use of modification dates. |  | use of modification dates. |
| 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 header fields |
| (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 "If-Match" request-header field is used to make a request method |  | The "If-Match" request-header field is used to make a request method |
| conditional. A client that has one or more representations |  | conditional. A client that has one or more representations |
| previously obtained from the resource can verify that one of those |  | previously obtained from the resource can verify that one of those |
| representations is current by including a list of their associated |  | representations is current by including a list of their associated |
| entity-tags in the If-Match header field. |  | entity-tags in the If-Match header field. |
| skipping to change at page 13, line 46 |  | skipping to change at page 14, line 46 |
| amount of transaction overhead. It is also used when updating |  | amount of transaction overhead. It is also used when updating |
| resources, to prevent inadvertent modification of the wrong version |  | resources, to prevent inadvertent modification of the wrong version |
| of a resource. As a special case, the value "*" matches any current |  | of a resource. As a special case, the value "*" matches any current |
| representation of the resource. |  | representation 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 representation |  | If any of the entity-tags match the entity-tag of the representation |
| that would have been returned in the response to a similar GET |  | that would have been returned in the response to a similar GET |
| request (without the If-Match header) on that resource, or if "*" is |  | request (without the If-Match header field) on that resource, or if |
| given and any current representation exists for that resource, then |  | "*" is given and any current representation exists for that resource, |
| the server MAY perform the requested method as if the If-Match header |  | then the server MAY perform the requested method as if the If-Match |
| field did not exist. |  | header field did not exist. |
| 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 |
| representation exists, the server MUST NOT perform the requested |  | representation exists, the server MUST NOT perform the requested |
| method, and MUST return a 412 (Precondition Failed) response. This |  | method, and MUST return a 412 (Precondition Failed) response. This |
| behavior is most useful when the client wants to prevent an updating |  | behavior is most useful when the client wants to prevent an updating |
| method, such as PUT, from modifying a resource that has changed since |  | method, such as PUT, from modifying a resource that has changed since |
| the client last retrieved it. |  | the client 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 code, then the If-Match |  | anything other than a 2xx or 412 status code, then the If-Match |
| header MUST be ignored. |  | header field MUST be ignored. |
| The meaning of "If-Match: *" is that the method SHOULD be performed |  | The meaning of "If-Match: *" is that the method SHOULD be performed |
| if the representation selected by the origin server (or by a cache, |  | if the representation selected by the origin server (or by a cache, |
| possibly using the Vary mechanism, see Section 3.5 of [Part6]) |  | possibly using the Vary mechanism, see Section 3.5 of [Part6]) |
| exists, and MUST NOT be performed if the representation does not |  | exists, and MUST NOT be performed if the representation does not |
| exist. |  | exist. |
| A request intended to update a resource (e.g., a PUT) MAY include an |  | A request intended to update a resource (e.g., a PUT) MAY include an |
| If-Match header field to signal that the request method MUST NOT be |  | If-Match header field to signal that the request method MUST NOT be |
| applied if the representation corresponding to the If-Match value (a |  | applied if the representation corresponding to the If-Match value (a |
| skipping to change at page 15, line 5 |  | skipping to change at page 16, line 5 |
| the method; instead, respond as detailed below. |  | the method; instead, respond as detailed below. |
| 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 field and no Range |
| requests that the representation be transferred only if it has been |  | header field requests that the representation be transferred only if |
| modified since the date given by the If-Modified-Since header. The |  | it has been modified since the date given by the If-Modified-Since |
| algorithm for determining this includes the following cases: |  | header field. 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 code, or if the passed If-Modified-Since date is |  | (OK) status code, or if the passed If-Modified-Since date is |
| invalid, the response is exactly the same as for a normal GET. A |  | invalid, the response is exactly the same as for a normal GET. A |
| date which is later than the server's current time is invalid. |  | date which is later than the server's current time is invalid. |
| 2. If the representation has been modified since the If-Modified- |  | 2. If the representation has been modified since the If-Modified- |
| Since date, the response is exactly the same as for a normal GET. |  | Since date, the response is exactly the same as for a normal GET. |
| 3. If the representation has not been modified since a valid If- |  | 3. If the representation has not been modified since a valid If- |
| skipping to change at page 15, line 40 |  | skipping to change at page 16, line 41 |
| Note: When handling an If-Modified-Since header field, some |  | Note: When handling an If-Modified-Since header field, some |
| servers will use an exact date comparison function, rather than a |  | servers will use an exact date comparison function, rather than a |
| less-than function, for deciding whether to send a 304 (Not |  | less-than function, for deciding whether to send a 304 (Not |
| Modified) response. To get best results when sending an If- |  | Modified) response. To get best results when sending an If- |
| Modified-Since header field for cache validation, clients are |  | Modified-Since header field for cache validation, clients are |
| advised to use the exact date string received in a previous Last- |  | advised to use the exact date string received in a previous Last- |
| Modified header field whenever possible. |  | Modified header field whenever possible. |
| Note: If a client uses an arbitrary date in the If-Modified-Since |  | Note: If a client uses an arbitrary date in the If-Modified-Since |
| header instead of a date taken from the Last-Modified header for |  | header field instead of a date taken from the Last-Modified header |
| the same request, the client needs to be aware that this date is |  | field for the same request, the client needs to be aware that this |
| interpreted in the server's understanding of time. Unsynchronized |  | date is interpreted in the server's understanding of time. |
| clocks and rounding problems, due to the different encodings of |  | Unsynchronized clocks and rounding problems, due to the different |
| time between the client and server, are concerns. This includes |  | encodings of time between the client and server, are concerns. |
| the possibility of race conditions if the document has changed |  | This includes the possibility of race conditions if the document |
| between the time it was first requested and the If-Modified-Since |  | has changed between the time it was first requested and the If- |
| date of a subsequent request, and the possibility of clock-skew- |  | Modified-Since date of a subsequent request, and the possibility |
| related problems if the If-Modified-Since date is derived from the |  | of clock-skew-related problems if the If-Modified-Since date is |
| client's clock without correction to the server's clock. |  | derived from the client's clock without correction to the server's |
| Corrections for different time bases between client and server are |  | clock. Corrections for different time bases between client and |
| at best approximate due to network latency. |  | server are at best approximate due to network latency. |
| The result of a request having both an If-Modified-Since header field |  | The result of a request having both an If-Modified-Since header field |
| and either an If-Match or an If-Unmodified-Since header fields is |  | and either an If-Match or an If-Unmodified-Since header fields is |
| undefined by this specification. |  | undefined by this specification. |
| 6.4. If-None-Match |  | 6.4. If-None-Match |
| The "If-None-Match" request-header field is used to make a request |  | The "If-None-Match" request-header field is used to make a request |
| method conditional. A client that has one or more representations |  | method conditional. A client that has one or more representations |
| previously obtained from the resource can verify that none of those |  | previously obtained from the resource can verify that none of those |
| skipping to change at page 16, line 30 |  | skipping to change at page 17, line 30 |
| 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 representation |  | As a special case, the value "*" matches any current representation |
| of the resource. |  | of the 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 |
| If any of the entity-tags match the entity-tag of the representation |  | If any of the entity-tags match the entity-tag of the representation |
| that would have been returned in the response to a similar GET |  | that would have been returned in the response to a similar GET |
| request (without the If-None-Match header) on that resource, or if |  | request (without the If-None-Match header field) on that resource, or |
| "*" is given and any current representation exists for that resource, |  | if "*" is given and any current representation exists for that |
| then the server MUST NOT perform the requested method, unless |  | resource, then the server MUST NOT perform the requested method, |
| required to do so because the resource's modification date fails to |  | unless required to do so because the resource's modification date |
| match that supplied in an If-Modified-Since header field in the |  | fails to match that supplied in an If-Modified-Since header field in |
| request. Instead, if the request method was GET or HEAD, the server |  | the request. Instead, if the request method was GET or HEAD, the |
| SHOULD respond with a 304 (Not Modified) response, including the |  | server SHOULD respond with a 304 (Not Modified) response, including |
| cache-related header fields (particularly ETag) of one of the |  | the cache-related header fields (particularly ETag) of one of the |
| representations that matched. For all other request methods, the |  | representations that matched. For all other request methods, the |
| server MUST respond with a 412 (Precondition Failed) status code. |  | server MUST respond with a 412 (Precondition Failed) status code. |
| 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 code, then the If-None- |  | in anything other than a 2xx or 304 status code, then the If-None- |
| Match header MUST be ignored. (See Section 5 for a discussion of |  | Match header field MUST be ignored. (See Section 5 for a discussion |
| server behavior when both If-Modified-Since and If-None-Match appear |  | of server behavior when both If-Modified-Since and If-None-Match |
| in the same request.) |  | appear in the same request.) |
| The meaning of "If-None-Match: *" is that the method MUST NOT be |  | The meaning of "If-None-Match: *" is that the method MUST NOT be |
| performed if the representation selected by the origin server (or by |  | performed if the representation selected by the origin server (or by |
| a cache, possibly using the Vary mechanism, see Section 3.5 of |  | a cache, possibly using the Vary mechanism, see Section 3.5 of |
| [Part6]) exists, and SHOULD be performed if the representation does |  | [Part6]) exists, and SHOULD be performed if the representation does |
| not exist. This feature is intended to be useful in preventing races |  | not exist. This feature is intended to be useful in preventing races |
| between PUT operations. |  | between PUT operations. |
| Examples: |  | Examples: |
| If-None-Match: "xyzzy" |  | If-None-Match: "xyzzy" |
| skipping to change at page 17, line 30 |  | skipping to change at page 18, line 30 |
| 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 "If-Unmodified-Since" request-header field is used to make a |  | The "If-Unmodified-Since" request-header field is used to make a |
| request method conditional. If the representation that would have |  | request method conditional. If the representation that would have |
| been transferred in a 200 response to a GET request on the same |  | been transferred in a 200 response to a GET request on the same |
| resource has not been modified since the time specified in this |  | resource has not been modified since the time specified in this |
| field, the server SHOULD perform the requested operation as if the |  | field, the server SHOULD perform the requested operation as if the |
| If-Unmodified-Since header were not present. |  | If-Unmodified-Since header field were not present. |
| If the representation has been modified since the specified time, the |  | If the representation has been modified since the specified time, the |
| server MUST NOT perform the requested operation, and MUST return a |  | server MUST NOT perform the requested operation, and MUST return a |
| 412 (Precondition Failed). |  | 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 |
| If-Unmodified-Since-v = HTTP-date |  | If-Unmodified-Since-v = HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| If the request normally (i.e., without the If-Unmodified-Since |  | If the request normally (i.e., without the If-Unmodified-Since header |
| header) would result in anything other than a 2xx or 412 status code, |  | field) would result in anything other than a 2xx or 412 status code, |
| the If-Unmodified-Since header SHOULD be ignored. |  | the If-Unmodified-Since header field SHOULD be ignored. |
| If the specified date is invalid, the header is ignored. |  | If the specified date is invalid, the header field 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 "Last-Modified" header field indicates the date and time at which |  | The "Last-Modified" header field indicates the date and time at which |
| the origin server believes the representation was last modified. |  | the origin server believes the representation was last modified. |
| skipping to change at page 19, line 51 |  | skipping to change at page 20, line 51 |
| 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-11 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-12 |
| (work in progress), August 2010. |  | (work in progress), October 2010. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] 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 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-11 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-12 |
| (work in progress), August 2010. |  | (work in progress), October 2010. |
| [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-11 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-12 (work |
| in progress), August 2010. |  | in progress), October 2010. |
| [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-11 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-12 (work in |
| progress), August 2010. |  | progress), October 2010. |
| [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 21, line 48 |  | skipping to change at page 22, line 48 |
| ; ETag defined but not used |  | ; ETag defined but not used |
| ; If-Match defined but not used |  | ; If-Match defined but not used |
| ; If-Modified-Since defined but not used |  | ; If-Modified-Since defined but not used |
| ; If-None-Match defined but not used |  | ; If-None-Match defined but not used |
| ; If-Unmodified-Since defined but not used |  | ; If-Unmodified-Since defined but not used |
| ; Last-Modified defined but not used |  | ; Last-Modified defined but not used |
| Appendix C. Change Log (to be removed by RFC Editor before publication) |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
| C.1. Since RFC2616 |  | C.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
| Informative references" |  | Informative references" |
| skipping to change at page 22, line 31 |  | skipping to change at page 23, line 31 |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |
| non-GET requests" |  | non-GET requests" |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Field Registration |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header field registrations for |
| defined in this document. |  | header fields defined in this document. |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for |
| ETag matching" |  | ETag matching" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity |
| value' undefined" |  | value' undefined" |
| skipping to change at page 23, line 16 |  | skipping to change at page 24, line 16 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Use "/" instead of "|" for alternatives. |  | o Use "/" instead of "|" for alternatives. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| value format definitions. |  | field value format definitions. |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 |
| Final work on ABNF conversion |  | Final work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| 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 |
| skipping to change at page 24, line 18 |  | skipping to change at page 25, line 18 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |
| 'Requested Variant'" |  | 'Requested Variant'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |
| entity / representation / variant terminology" |  | entity / representation / variant terminology" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
| removing the 'changes from 2068' sections" |  | removing the 'changes from 2068' sections" |
|  |  | C.13. Since draft-ietf-httpbis-p4-conditional-11 |
|  |  | None. |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 7 |  | 304 Not Modified (status code) 8 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 7 |  | 412 Precondition Failed (status code) 8 |
| E |  | E |
| ETag header 12 |  | ETag header 13 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 5 |  | entity-tag 6 |
| ETag 12 |  | ETag 13 |
| ETag-v 12 |  | ETag-v 13 |
| If-Match 13 |  | If-Match 14 |
| If-Match-v 13 |  | If-Match-v 14 |
| If-Modified-Since 14 |  | If-Modified-Since 15 |
| If-Modified-Since-v 14 |  | If-Modified-Since-v 15 |
| If-None-Match 16 |  | If-None-Match 17 |
| If-None-Match-v 16 |  | If-None-Match-v 17 |
| If-Unmodified-Since 17 |  | If-Unmodified-Since 18 |
| If-Unmodified-Since-v 17 |  | If-Unmodified-Since-v 18 |
| Last-Modified 18 |  | Last-Modified 19 |
| Last-Modified-v 18 |  | Last-Modified-v 19 |
| opaque-tag 5 |  | opaque-tag 6 |
| weak 5 |  | weak 6 |
| H |  | H |
| Headers |  | Headers |
| ETag 12 |  | ETag 13 |
| If-Match 13 |  | If-Match 14 |
| If-Modified-Since 14 |  | If-Modified-Since 15 |
| If-None-Match 16 |  | If-None-Match 17 |
| If-Unmodified-Since 17 |  | If-Unmodified-Since 18 |
| Last-Modified 18 |  | Last-Modified 19 |
| I |  | I |
| If-Match header 13 |  | If-Match header 14 |
| If-Modified-Since header 14 |  | If-Modified-Since header 15 |
| If-None-Match header 16 |  | If-None-Match header 17 |
| If-Unmodified-Since header 17 |  | If-Unmodified-Since header 18 |
| L |  | L |
| Last-Modified header 18 |  | Last-Modified header 19 |
| S |  | S |
| Status Codes |  | Status Codes |
| 304 Not Modified 7 |  | 304 Not Modified 8 |
| 412 Precondition Failed 7 |  | 412 Precondition Failed 8 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 40 change blocks.
| 136 lines changed or deleted |  | 143 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/