| draft-ietf-httpbis-p4-conditional-04.txt |  | draft-ietf-httpbis-p4-conditional-05.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network 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: March 2, 2009 J. Mogul |  | Expires: May 20, 2009 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 29, 2008 |  | November 16, 2008 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-04 |  | draft-ietf-httpbis-p4-conditional-05 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 49 |
| 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 March 2, 2009. |  | This Internet-Draft will expire on May 20, 2009. |
| 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://www.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://www.tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix B.4. |  | The changes in this draft are summarized in Appendix B.6. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 |
| 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |
| 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |  | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |
| skipping to change at page 3, line 25 |  | skipping to change at page 3, line 25 |
| 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |  | 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |
| 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |  | 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |
| 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |  | 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |
| 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |  | 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |
| 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |
| 8.1. Message Header Registration . . . . . . . . . . . . . . . 17 |  | 8.1. Message Header Registration . . . . . . . . . . . . . . . 17 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 18 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 18 |
| A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 |  | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 19 |  | publication) . . . . . . . . . . . . . . . . . . . . 19 |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 |
| B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19 |  | B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19 |
| B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19 |  | B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19 |
| B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19 |  | B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19 |
| B.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 19 |  | B.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 20 |
|  |  | B.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 20 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 24 |  | Intellectual Property and Copyright Statements . . . . . . . . . . 24 |
| 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. |
| skipping to change at page 4, line 47 |  | skipping to change at page 4, line 47 |
| REQUIRED level and all the SHOULD level requirements for its |  | REQUIRED level and all the SHOULD level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the MUST level requirements but not all the SHOULD |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant." |
| 2. Notational Conventions and Generic Grammar |  | 2. Notational Conventions and Generic Grammar |
| This specification uses the ABNF syntax defined in Section 2.1 of |  | This specification uses the ABNF syntax defined in Section 2.1 of |
| [Part1] and the core rules defined in Section 2.2 of [Part1]: |  | [Part1] and the core rules defined in Section 2.2 of [Part1]: |
| [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC |  |  |
| 5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]] |  |  |
| quoted-string = <quoted-string, defined in [Part1], Section 2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 2.2> |
|  |  | OWS = <OWS, defined in [Part1], Section 2.2> |
| 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.3.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> |
| 3. Entity Tags |  | 3. 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 7.1), If-Match (Section 7.2), If-None-Match (Section 7.4), |  | (Section 7.1), If-Match (Section 7.2), If-None-Match (Section 7.4), |
| and If-Range (Section 6.3 of [Part5]) header fields. The definition |  | and If-Range (Section 6.3 of [Part5]) header fields. The definition |
| skipping to change at page 11, line 30 |  | skipping to change at page 11, line 27 |
| 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. |
| 7.1. ETag |  | 7.1. ETag |
| The ETag response-header field provides the current value of the |  | The response-header field "ETag" provides the current value of the |
| entity tag for the requested variant. The headers used with entity |  | entity tag (see Section 3) for the requested variant. The headers |
| tags are described in Sections 7.2 and 7.4 of this document, and in |  | used with entity tags are described in Sections 7.2 and 7.4 of this |
| Section 6.3 of [Part5]. The entity tag MAY be used for comparison |  | document, and in Section 6.3 of [Part5]. The entity tag MAY be used |
| with other entities from the same resource (see Section 5). |  | for comparison with other entities from the same resource (see |
|  |  | Section 5). |
| ETag = "ETag" ":" entity-tag |  | ETag = "ETag" ":" OWS ETag-v |
|  |  | ETag-v = entity-tag |
| Examples: |  | Examples: |
| ETag: "xyzzy" |  | ETag: "xyzzy" |
| ETag: W/"xyzzy" |  | ETag: W/"xyzzy" |
| ETag: "" |  | ETag: "" |
| The ETag response-header field value, an entity tag, provides for an |  | The ETag response-header field value, an entity tag, provides for an |
| "opaque" cache validator. This might allow more reliable validation |  | "opaque" cache validator. This might allow more reliable validation |
| in situations where it is inconvenient to store modification dates, |  | in situations where it is inconvenient to store modification dates, |
| skipping to change at page 12, line 13 |  | skipping to change at page 12, line 12 |
| 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. |
| 7.2. If-Match |  | 7.2. If-Match |
| The If-Match request-header field is used with a method to make it |  | The request-header field "If-Match" is used with a method to make it |
| 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 3. The |  | If-Match header field. Entity tags are defined in Section 3. The |
| purpose of this feature is to allow efficient updates of cached |  | purpose of this feature is to allow efficient updates of cached |
| information with a minimum amount of transaction overhead. It is |  | information with a minimum amount of transaction overhead. It is |
| also used, on updating requests, to prevent inadvertent modification |  | also used, on updating requests, to prevent inadvertent modification |
| of the wrong version of a resource. As a special case, the value "*" |  | of the wrong version of a resource. As a special case, the value "*" |
| matches any current entity of the resource. |  | matches any current entity of the resource. |
| If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) |  | If-Match = "If-Match" ":" OWS If-Match-v |
|  |  | 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 5) to |  | A server MUST use the strong comparison function (see Section 5) to |
| compare the entity tags in If-Match. |  | compare the entity tags in If-Match. |
| skipping to change at page 13, line 23 |  | skipping to change at page 13, line 23 |
| 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. |
| 7.3. If-Modified-Since |  | 7.3. If-Modified-Since |
| The If-Modified-Since request-header field is used with a method to |  | The request-header field "If-Modified-Since" is used with a method to |
| make it conditional: if the requested variant has not been modified |  | make it conditional: if the requested variant has not been modified |
| since the time specified in this field, an entity will not be |  | since the time specified in this field, an entity will not be |
| returned from the server; instead, a 304 (Not Modified) response will |  | returned from the server; instead, a 304 (Not Modified) response will |
| be returned without any message-body. |  | be returned without any message-body. |
| If-Modified-Since = "If-Modified-Since" ":" HTTP-date |  | If-Modified-Since = "If-Modified-Since" ":" OWS |
|  |  | If-Modified-Since-v |
|  |  | 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: |
| skipping to change at page 14, line 41 |  | skipping to change at page 14, line 43 |
| 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. |
| 7.4. If-None-Match |  | 7.4. If-None-Match |
| The If-None-Match request-header field is used with a method to make |  | The request-header field "If-None-Match" is used with a method to |
| it conditional. A client that has one or more entities previously |  | make it conditional. A client that has one or more entities |
| obtained from the resource can verify that none of those entities is |  | previously obtained from the resource can verify that none of those |
| current by including a list of their associated entity tags in the |  | entities is current by including a list of their associated entity |
| If-None-Match header field. The purpose of this feature is to allow |  | tags in the If-None-Match header field. The purpose of this feature |
| efficient updates of cached information with a minimum amount of |  | is to allow efficient updates of cached information with a minimum |
| transaction overhead. It is also used to prevent a method (e.g. |  | amount of transaction overhead. It is also used to prevent a method |
| PUT) from inadvertently modifying an existing resource when the |  | (e.g. PUT) from inadvertently modifying an existing resource when |
| 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" ":" ( "*" | 1#entity-tag ) |  | If-None-Match = "If-None-Match" ":" OWS If-None-Match-v |
|  |  | If-None-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-None-Match header) on that resource, or if "*" is |  | (without the If-None-Match header) on that resource, or if "*" is |
| 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- |
| skipping to change at page 15, line 49 |  | skipping to change at page 16, line 4 |
| 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" |
| If-None-Match: W/"xyzzy" |  | If-None-Match: W/"xyzzy" |
| If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |  | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
| If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |  | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
| If-None-Match: * |  | If-None-Match: * |
| The result of a request having both an If-None-Match header field and |  | The result of a request having both an If-None-Match header field and |
| either an If-Match or an If-Unmodified-Since header fields is |  | either an If-Match or an If-Unmodified-Since header fields is |
| undefined by this specification. |  | undefined by this specification. |
| 7.5. If-Unmodified-Since |  | 7.5. If-Unmodified-Since |
| The If-Unmodified-Since request-header field is used with a method to |  | The request-header field "If-Unmodified-Since" is used with a method |
| make it conditional. If the requested resource has not been modified |  | to make it conditional. If the requested resource has not been |
| since the time specified in this field, the server SHOULD perform the |  | modified since the time specified in this field, the server SHOULD |
| requested operation as if the If-Unmodified-Since header were not |  | perform the requested operation as if the If-Unmodified-Since header |
| 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" ":" HTTP-date |  | If-Unmodified-Since = "If-Unmodified-Since" ":" OWS |
|  |  | If-Unmodified-Since-v |
|  |  | 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) would result in anything other than a 2xx or 412 status, the |  | header) would result in anything other than a 2xx or 412 status, the |
| 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. |
| 7.6. Last-Modified |  | 7.6. Last-Modified |
| The Last-Modified entity-header field indicates the date and time at |  | The entity-header field "Last-Modified" indicates the date and time |
| 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" ":" HTTP-date |  | Last-Modified = "Last-Modified" ":" OWS Last-Modified-v |
|  |  | 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 |
| of the origin server and the nature of the original resource. For |  | of the origin server and the nature of the original resource. For |
| files, it may be just the file system last-modified time. For |  | files, it may be just the file system last-modified time. For |
| entities with dynamically included parts, it may be the most recent |  | entities with dynamically included parts, it may be the most recent |
| of the set of last-modify times for its component parts. For |  | of the set of last-modify times for its component parts. For |
| skipping to change at page 18, line 14 |  | skipping to change at page 18, line 19 |
| 10. Acknowledgments |  | 10. Acknowledgments |
| 11. References |  | 11. References |
| 11.1. Normative References |  | 11.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-04 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-05 |
| (work in progress), August 2008. |  | (work in progress), November 2008. |
| [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-04 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-05 (work |
| in progress), August 2008. |  | in progress), November 2008. |
| [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., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-04 (work in progress), |  | draft-ietf-httpbis-p6-cache-05 (work in progress), |
| August 2008. |  | November 2008. |
| [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. |
| 11.2. Informative References |  | 11.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| skipping to change at page 19, line 15 |  | skipping to change at page 19, line 20 |
| Appendix B. Change Log (to be removed by RFC Editor before publication) |  | Appendix B. Change Log (to be removed by RFC Editor before publication) |
| B.1. Since RFC2616 |  | B.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| B.2. Since draft-ietf-httpbis-p4-conditional-00 |  | B.2. Since draft-ietf-httpbis-p4-conditional-00 |
| Closed issues: |  | Closed issues: |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
| and Informative references" |  | Informative references" |
| Other changes: |  | Other changes: |
| o Move definitions of 304 and 412 condition codes from Part2. |  | o Move definitions of 304 and 412 condition codes from Part2. |
| B.3. Since draft-ietf-httpbis-p4-conditional-01 |  | B.3. Since draft-ietf-httpbis-p4-conditional-01 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| 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. |
| B.4. Since draft-ietf-httpbis-p4-conditional-02 |  | B.4. Since draft-ietf-httpbis-p4-conditional-02 |
| Closed issues: |  | Closed issues: |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |
| ETags on non-GET requests" |  | non-GET requests" |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Registration |
| (<http://www3.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 registrations for headers |
| defined in this document. |  | defined in this document. |
| B.5. Since draft-ietf-httpbis-p4-conditional-03 |  | B.5. Since draft-ietf-httpbis-p4-conditional-03 |
| Closed issues: |  | Closed issues: |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for |
| for ETag matching" |  | ETag matching" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity |
| value' undefined" |  | value' undefined" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus |  |  |
| 2068 Date header reference" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068 |
|  |  | Date header reference" |
|  |  | B.6. Since draft-ietf-httpbis-p4-conditional-04 |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Use "/" instead of "|" for alternatives. |
|  |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
|  |  | whitespace ("OWS") and required whitespace ("RWS"). |
|  |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
|  |  | value format definitions. |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 5 |  | 304 Not Modified (status code) 5 |
| 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 |
| If-Match 12 |  | If-Match 12 |
|  |  | If-Match-v 12 |
| If-Modified-Since 13 |  | If-Modified-Since 13 |
|  |  | If-Modified-Since-v 13 |
| If-None-Match 15 |  | If-None-Match 15 |
|  |  | If-None-Match-v 15 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 16 |
|  |  | If-Unmodified-Since-v 16 |
| Last-Modified 16 |  | Last-Modified 16 |
|  |  | Last-Modified-v 16 |
| opaque-tag 5 |  | opaque-tag 5 |
| weak 5 |  | weak 5 |
| H |  | H |
| Headers |  | Headers |
| ETag 11 |  | ETag 11 |
| If-Match 12 |  | If-Match 12 |
| If-Modified-Since 13 |  | If-Modified-Since 13 |
| If-None-Match 14 |  | If-None-Match 14 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 16 |
End of changes. 41 change blocks.
| 59 lines changed or deleted |  | 88 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/