| draft-ietf-httpbis-p4-conditional-05.txt |  | draft-ietf-httpbis-p4-conditional-06.txt |
--- | --- | --- | --- | ---
| Network 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: May 20, 2009 J. Mogul |  | Expires: September 10, 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 |
| November 16, 2008 |  | March 9, 2009 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-05 |  | draft-ietf-httpbis-p4-conditional-06 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | This Internet-Draft is submitted to IETF in full conformance with the |
| applicable patent or other IPR claims of which he or she is aware |  | provisions of BCP 78 and BCP 79. This document may contain material |
| have been or will be disclosed, and any of which he or she becomes |  | from IETF Documents or IETF Contributions published or made publicly |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | available before November 10, 2008. The person(s) controlling the |
|  |  | copyright in some of this material may not have granted the IETF |
|  |  | Trust the right to allow modifications of such material outside the |
|  |  | IETF Standards Process. Without obtaining an adequate license from |
|  |  | the person(s) controlling the copyright in such materials, this |
|  |  | document may not be modified outside the IETF Standards Process, and |
|  |  | derivative works of it may not be created outside the IETF Standards |
|  |  | Process, except to format it for publication as an RFC or to |
|  |  | translate it into languages other than English. |
| 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 |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| 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." |
| skipping to change at page 1, line 42 |  | skipping to change at page 2, line 4 |
| 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 |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| 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 May 20, 2009. |  | This Internet-Draft will expire on September 10, 2009. |
|  |  | Copyright Notice |
|  |  | Copyright (c) 2009 IETF Trust and the persons identified as the |
|  |  | document authors. All rights reserved. |
|  |  | This document is subject to BCP 78 and the IETF Trust's Legal |
|  |  | Provisions Relating to IETF Documents in effect on the date of |
|  |  | publication of this document (http://trustee.ietf.org/license-info). |
|  |  | Please review these documents carefully, as they describe your rights |
|  |  | and restrictions with respect to this document. |
| 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/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 B.6. |  | The changes in this draft are summarized in Appendix C.7. |
| 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 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 1.2.2. ABNF Rules defined in other Parts of the |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |  | Specification . . . . . . . . . . . . . . . . . . . . 5 |
| 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |  | 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 5. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 |
| 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |  | 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 6 |
| 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |  | 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |
| 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7 |
| 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |
| 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |
| 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |  | 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |  | 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |  | 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |  | 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |
| 8.1. Message Header Registration . . . . . . . . . . . . . . . 17 |  | 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 |  | 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 7.1. Message Header Registration . . . . . . . . . . . . . . . 17 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 18 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
|  |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |
|  |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 |
|  |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 19 |
| A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 |  | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 |
| publication) . . . . . . . . . . . . . . . . . . . . 19 |  | Appendix C. Change Log (to be removed by RFC Editor before |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 |  | publication) . . . . . . . . . . . . . . . . . . . . 20 |
| B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 |
| B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21 |
| B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21 |
| B.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 20 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21 |
| B.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 20 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 24 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
|  |  | 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 |
| 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 |
| skipping to change at page 4, line 43 |  | skipping to change at page 4, line 43 |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the MUST or REQUIRED level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the MUST or |
| 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 |  | 1.2. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 2.1 of |  | This specification uses the ABNF syntax defined in Section 1.2 of |
| [Part1] and the core rules defined in Section 2.2 of [Part1]: |  | [Part1] (which extends the syntax defined in [RFC5234] with a list |
|  |  | rule). Appendix B shows the collected ABNF, with the list rule |
|  |  | expanded. |
| quoted-string = <quoted-string, defined in [Part1], Section 2.2> |  | The following core rules are included by reference, as defined in |
| OWS = <OWS, defined in [Part1], Section 2.2> |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
|  |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
|  |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
|  |  | sequence of data), SP (space), VCHAR (any visible USASCII character), |
|  |  | and WSP (whitespace). |
|  |  | 1.2.1. Core Rules |
|  |  | The core rules below are defined in Section 1.2.2 of [Part1]: |
|  |  | quoted-string = <quoted-string, 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 |
| 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.2.1> |
| 3. 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 7.1), If-Match (Section 7.2), If-None-Match (Section 7.4), |  | (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4), |
| and If-Range (Section 6.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 5. 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. |
| entity-tag = [ weak ] opaque-tag |  | entity-tag = [ weak ] opaque-tag |
| weak = "W/" |  | weak = "W/" |
| opaque-tag = quoted-string |  | opaque-tag = quoted-string |
| A "strong entity tag" MAY be shared by two entities of a resource |  | A "strong entity tag" MAY be shared by two entities of a resource |
| only if they are equivalent by octet equality. |  | only if they are equivalent by octet equality. |
| A "weak entity tag," indicated by the "W/" prefix, MAY be shared by |  | A "weak entity tag," indicated by the "W/" prefix, MAY be shared by |
| skipping to change at page 5, line 36 |  | skipping to change at page 6, line 5 |
| could be substituted for each other with no significant change in |  | could be substituted for each other with no significant change in |
| semantics. A weak entity tag can only be used for weak comparison. |  | semantics. A weak entity tag can only be used for weak comparison. |
| An entity tag MUST be unique across all versions of all entities |  | An entity tag MUST be unique across all versions of all entities |
| associated with a particular resource. A given entity tag value MAY |  | associated with a particular resource. A given entity tag value MAY |
| be used for entities obtained by requests on different URIs. The use |  | be used for entities obtained by requests on different URIs. The use |
| of the same entity tag value in conjunction with entities obtained by |  | of the same entity tag value in conjunction with entities obtained by |
| requests on different URIs does not imply the equivalence of those |  | requests on different URIs does not imply the equivalence of those |
| entities. |  | entities. |
| 4. Status Code Definitions |  | 3. Status Code Definitions |
| 4.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 8.3.1 of [Part1]. |
| skipping to change at page 6, line 15 |  | skipping to change at page 6, line 31 |
| (as already specified by Section 8.3 of [Part1], caches will |  | (as already specified by Section 8.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 5), |  | If the conditional GET used a strong cache validator (see Section 4), |
| the response SHOULD NOT include other entity-headers. Otherwise |  | the response SHOULD NOT include other entity-headers. Otherwise |
| (i.e., the conditional GET used a weak validator), the response MUST |  | (i.e., the conditional GET used a weak validator), the response MUST |
| NOT include other entity-headers; this prevents inconsistencies |  | NOT include other entity-headers; this prevents inconsistencies |
| between cached entity-bodies and updated headers. |  | between cached entity-bodies and updated headers. |
| If a 304 response indicates an entity not currently cached, then the |  | If a 304 response indicates an entity not currently cached, then the |
| cache MUST disregard the response and repeat the request without the |  | cache MUST disregard the response and repeat the request without the |
| conditional. |  | conditional. |
| If a cache uses a received 304 response to update a cache entry, the |  | If a cache uses a received 304 response to update a cache entry, the |
| cache MUST update the entry to reflect any new field values given in |  | cache MUST update the entry to reflect any new field values given in |
| the response. |  | the response. |
| 4.2. 412 Precondition Failed |  | 3.2. 412 Precondition Failed |
| The precondition given in one or more of the request-header fields |  | The precondition given in one or more of the request-header fields |
| evaluated to false when it was tested on the server. This response |  | evaluated to false when it was tested on the server. This response |
| code allows the client to place preconditions on the current resource |  | code allows the client to place preconditions on the current resource |
| metainformation (header field data) and thus prevent the requested |  | metainformation (header field data) and thus prevent the requested |
| method from being applied to a resource other than the one intended. |  | method from being applied to a resource other than the one intended. |
| 5. Weak and Strong Validators |  | 4. Weak and Strong Validators |
| Since both origin servers and caches will compare two validators to |  | Since both origin servers and caches will compare two validators to |
| decide if they represent the same or different entities, one normally |  | decide if they represent the same or different entities, one normally |
| would expect that if the entity (the entity-body or any entity- |  | would expect that if the entity (the entity-body or any entity- |
| headers) changes in any way, then the associated validator would |  | headers) changes in any way, then the associated validator would |
| change as well. If this is true, then we call this validator a |  | change as well. If this is true, then we call this validator a |
| "strong validator." |  | "strong validator." |
| However, there might be cases when a server prefers to change the |  | However, there might be cases when a server prefers to change the |
| validator only on semantically significant changes, and not when |  | validator only on semantically significant changes, and not when |
| skipping to change at page 8, line 15 |  | skipping to change at page 8, line 29 |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | |  | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| | W/"1" | W/"1" | no match | match | |  | | W/"1" | W/"1" | no match | match | |
| | W/"1" | W/"2" | no match | no match | |  | | W/"1" | W/"2" | no match | no match | |
| | W/"1" | "1" | no match | match | |  | | W/"1" | "1" | no match | match | |
| | "1" | "1" | match | match | |  | | "1" | "1" | match | match | |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| An entity tag is strong unless it is explicitly tagged as weak. |  | An entity tag is strong unless it is explicitly tagged as weak. |
| Section 3 gives the syntax for entity tags. |  | Section 2 gives the syntax for entity tags. |
| A Last-Modified time, when used as a validator in a request, is |  | A Last-Modified time, when used as a validator in a request, is |
| implicitly weak unless it is possible to deduce that it is strong, |  | implicitly weak unless it is possible to deduce that it is strong, |
| using the following rules: |  | using the following rules: |
| 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 entity and, |  | current validator for the entity and, |
| o That origin server reliably knows that the associated entity did |  | o That origin server reliably knows that the associated entity did |
| not change twice during the second covered by the presented |  | not change twice during the second covered by the presented |
| skipping to change at page 9, line 25 |  | skipping to change at page 9, line 39 |
| described here. |  | described here. |
| A cache or origin server receiving a conditional range request |  | A cache or origin server receiving a conditional range request |
| ([Part5]) MUST use the strong comparison function to evaluate the |  | ([Part5]) MUST use the strong comparison function to evaluate the |
| condition. |  | condition. |
| These rules allow HTTP/1.1 caches and clients to safely perform sub- |  | These rules allow HTTP/1.1 caches and clients to safely perform sub- |
| range retrievals on values that have been obtained from HTTP/1.0 |  | range retrievals on values that have been obtained from HTTP/1.0 |
| servers. |  | servers. |
| 6. Rules for When to Use Entity Tags and Last-Modified Dates |  | 5. Rules for When to Use Entity Tags and Last-Modified Dates |
| We adopt a set of rules and recommendations for origin servers, |  | We adopt a set of rules and recommendations for origin servers, |
| clients, and caches regarding when various validator types ought to |  | clients, and caches regarding when various validator types ought to |
| be used, and for what purposes. |  | be used, and for what purposes. |
| HTTP/1.1 origin servers: |  | HTTP/1.1 origin servers: |
| 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. |
| skipping to change at page 11, line 16 |  | skipping to change at page 11, line 28 |
| conservative assumptions about the validators they receive. |  | conservative assumptions about the validators they receive. |
| HTTP/1.0 clients and caches will ignore entity tags. Generally, |  | HTTP/1.0 clients and caches will ignore entity tags. Generally, |
| last-modified values received or used by these systems will |  | last-modified values received or used by these systems will |
| support transparent and efficient caching, and so HTTP/1.1 origin |  | support transparent and efficient caching, and so HTTP/1.1 origin |
| servers should provide Last-Modified values. In those rare cases |  | servers should provide Last-Modified values. In those rare cases |
| where the use of a Last-Modified value as a validator by an |  | where the use of a Last-Modified value as a validator by an |
| HTTP/1.0 system could result in a serious problem, then HTTP/1.1 |  | HTTP/1.0 system could result in a serious problem, then HTTP/1.1 |
| origin servers should not provide one. |  | origin servers should not provide one. |
| 7. Header Field Definitions |  | 6. Header Field Definitions |
| 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 |  | 6.1. ETag |
| The response-header field "ETag" provides the current value of the |  | The response-header field "ETag" provides the current value of the |
| entity tag (see Section 3) for the requested variant. The headers |  | entity tag (see Section 2) for the requested variant. The headers |
| used with entity tags are described in Sections 7.2 and 7.4 of this |  | used with entity tags are described in Sections 6.2 and 6.4 of this |
| document, and in Section 6.3 of [Part5]. The entity tag MAY be used |  | document, and in Section 5.3 of [Part5]. The entity tag MAY be used |
| for comparison with other entities from the same resource (see |  | for comparison with other entities from the same resource (see |
| Section 5). |  | 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: "" |
| 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, |
| where the one-second resolution of HTTP date values is not |  | where the one-second resolution of HTTP date values is not |
| skipping to change at page 12, line 10 |  | skipping to change at page 12, line 25 |
| paradoxes that might arise from the use of modification dates. |  | paradoxes that might arise from the 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 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 |  | 6.2. If-Match |
| The request-header field "If-Match" 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 2. 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" ":" 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 5) to |  | A server MUST use the strong comparison function (see Section 4) to |
| compare the entity tags in If-Match. |  | 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. |
| 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 16.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 entity corresponding to the If-Match value (a single |  | applied if the entity corresponding to the If-Match value (a single |
| entity tag) is no longer a representation of that resource. This |  | entity tag) is no longer a representation of that resource. This |
| allows the user to indicate that they do not wish the request to be |  | allows the user to indicate that they do not wish the request to be |
| successful if the resource has been changed without their knowledge. |  | successful if the resource has been changed without their knowledge. |
| Examples: |  | Examples: |
| 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 |  | 6.3. If-Modified-Since |
| The request-header field "If-Modified-Since" 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" ":" 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 |
| skipping to change at page 14, line 9 |  | skipping to change at page 14, line 25 |
| date, the response is exactly the same as for a normal GET. |  | date, the response is exactly the same as for a normal GET. |
| 3. If the variant has not been modified since a valid If-Modified- |  | 3. If the variant has not been modified since a valid If-Modified- |
| Since date, the server SHOULD return a 304 (Not Modified) |  | Since date, the server SHOULD return a 304 (Not Modified) |
| response. |  | response. |
| The purpose of this feature is to allow efficient updates of cached |  | The purpose of this feature is to allow efficient updates of cached |
| information with a minimum amount of transaction overhead. |  | information with a minimum amount of transaction overhead. |
| Note: The Range request-header field modifies the meaning of If- |  | Note: The Range request-header field modifies the meaning of If- |
| Modified-Since; see Section 6.4 of [Part5] for full details. |  | Modified-Since; see Section 5.4 of [Part5] for full details. |
| Note: If-Modified-Since times are interpreted by the server, whose |  | Note: If-Modified-Since times are interpreted by the server, whose |
| clock might not be synchronized with the client. |  | clock might not be synchronized with the client. |
| 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- |
| skipping to change at page 14, line 41 |  | skipping to change at page 15, line 9 |
| possibility of clock-skew-related problems if the If-Modified- |  | possibility of clock-skew-related problems if the If-Modified- |
| Since date is derived from the client's clock without correction |  | Since date is derived from the client's clock without correction |
| 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 |  | 6.4. If-None-Match |
| The request-header field "If-None-Match" is used with a method to |  | The request-header field "If-None-Match" is used with a method to |
| make it conditional. A client that has one or more entities |  | make it 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. The purpose of this feature |
| is to allow efficient updates of cached information with a minimum |  | is to allow 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. |
| skipping to change at page 15, line 24 |  | skipping to change at page 15, line 40 |
| 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 5 for rules on how to determine if two entity tags match. |  | 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 6 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 |
| same request.) |  | 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 16.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" |
| 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" |
| skipping to change at page 16, line 4 |  | skipping to change at page 16, line 18 |
| 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 |  | 6.5. If-Unmodified-Since |
| The request-header field "If-Unmodified-Since" is used with a method |  | The request-header field "If-Unmodified-Since" is used with a method |
| to make it conditional. If the requested resource has not been |  | to make it 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). |
| skipping to change at page 16, line 38 |  | skipping to change at page 17, line 5 |
| 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 |  | 6.6. Last-Modified |
| The entity-header field "Last-Modified" indicates the date and time |  | The entity-header field "Last-Modified" 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 |
| skipping to change at page 17, line 29 |  | skipping to change at page 17, line 44 |
| its response. This allows a recipient to make an accurate assessment |  | its response. This allows a recipient to make an accurate assessment |
| of the entity's modification time, especially if the entity changes |  | of the entity's modification time, especially if the entity changes |
| 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. |
| 8. IANA Considerations |  | 7. IANA Considerations |
| 8.1. Message Header Registration |  | 7.1. 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 7.1 | |  | | ETag | http | standard | Section 6.1 | |
| | If-Match | http | standard | Section 7.2 | |  | | If-Match | http | standard | Section 6.2 | |
| | If-Modified-Since | http | standard | Section 7.3 | |  | | If-Modified-Since | http | standard | Section 6.3 | |
| | If-None-Match | http | standard | Section 7.4 | |  | | If-None-Match | http | standard | Section 6.4 | |
| | If-Unmodified-Since | http | standard | Section 7.5 | |  | | If-Unmodified-Since | http | standard | Section 6.5 | |
| | Last-Modified | http | standard | Section 7.6 | |  | | Last-Modified | http | standard | Section 6.6 | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 9. Security Considerations |  | 8. Security Considerations |
| No additional security considerations have been identified beyond |  | No additional security considerations have been identified beyond |
| those applicable to HTTP in general [Part1]. |  | those applicable to HTTP in general [Part1]. |
| 10. Acknowledgments |  | 9. Acknowledgments |
| 11. References |  | 10. References |
| 11.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-05 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-06 |
| (work in progress), November 2008. |  | (work in progress), March 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-05 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-06 (work |
| in progress), November 2008. |  | in progress), March 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., |
| 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-05 (work in progress), |  | draft-ietf-httpbis-p6-cache-06 (work in progress), |
| November 2008. |  | March 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. |
| 11.2. Informative References |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
|  |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
|  |  | 10.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. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| Appendix A. Compatibility with Previous Versions |  | Appendix A. Compatibility with Previous Versions |
| 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 5 and 7.4). |  | (Sections 4 and 6.4). |
| Appendix B. Change Log (to be removed by RFC Editor before publication) |  | Appendix B. Collected ABNF |
| B.1. Since RFC2616 |  | ETag = "ETag:" OWS ETag-v |
|  |  | ETag-v = entity-tag |
|  |  | HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> |
|  |  | If-Match = "If-Match:" OWS If-Match-v |
|  |  | If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
|  |  | entity-tag ] ) ) |
|  |  | If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v |
|  |  | If-Modified-Since-v = HTTP-date |
|  |  | If-None-Match = "If-None-Match:" OWS If-None-Match-v |
|  |  | If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
|  |  | entity-tag ] ) ) |
|  |  | If-Unmodified-Since = "If-Unmodified-Since:" OWS |
|  |  | If-Unmodified-Since-v |
|  |  | If-Unmodified-Since-v = HTTP-date |
|  |  | Last-Modified = "Last-Modified:" OWS Last-Modified-v |
|  |  | Last-Modified-v = HTTP-date |
|  |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
|  |  | entity-tag = [ weak ] opaque-tag |
|  |  | opaque-tag = quoted-string |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
|  |  | weak = "W/" |
|  |  | ABNF diagnostics: |
|  |  | ; ETag defined but not used |
|  |  | ; If-Match defined but not used |
|  |  | ; If-Modified-Since defined but not used |
|  |  | ; If-None-Match defined but not used |
|  |  | ; If-Unmodified-Since defined but not used |
|  |  | ; Last-Modified defined but not used |
|  |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
|  |  | C.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| B.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" |
| 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 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 |
| 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 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 |  | 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 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 registrations for headers |
| defined in this document. |  | defined in this document. |
| B.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" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068 |
| Date header reference" |  | Date header reference" |
| B.6. Since draft-ietf-httpbis-p4-conditional-04 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 |
| 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. |  | value format definitions. |
|  |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 |
|  |  | Final work on ABNF conversion |
|  |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Add appendix containing collected and expanded ABNF, reorganize |
|  |  | ABNF introduction. |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 5 |  | 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 |
| If-Modified-Since 13 |  | If-Modified-Since 13 |
| If-Modified-Since-v 13 |  | If-Modified-Since-v 13 |
| If-None-Match 15 |  | If-None-Match 15 |
| If-None-Match-v 15 |  | If-None-Match-v 15 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 16 |
| If-Unmodified-Since-v 16 |  | If-Unmodified-Since-v 16 |
| Last-Modified 16 |  | Last-Modified 17 |
| Last-Modified-v 16 |  | Last-Modified-v 17 |
| 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 15 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 16 |
| Last-Modified 16 |  | Last-Modified 17 |
| I |  | I |
| If-Match header 12 |  | If-Match header 12 |
| If-Modified-Since header 13 |  | If-Modified-Since header 13 |
| If-None-Match header 14 |  | If-None-Match header 15 |
| If-Unmodified-Since header 16 |  | If-Unmodified-Since header 16 |
| L |  | L |
| Last-Modified header 16 |  | Last-Modified header 17 |
| S |  | S |
| Status Codes |  | Status Codes |
| 304 Not Modified 5 |  | 304 Not Modified 6 |
| 412 Precondition Failed 6 |  | 412 Precondition Failed 6 |
| 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 |
| skipping to change at page 24, line 4 |  | skipping to change at line 1114 |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  | Phone: +49 251 2807760 |
| Fax: +49 251 2807761 |  | Fax: +49 251 2807761 |
| Email: julian.reschke@greenbytes.de |  | Email: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  |  |
| Copyright (C) The IETF Trust (2008). |  |  |
| This document is subject to the rights, licenses and restrictions |  |  |
| contained in BCP 78, and except as set forth therein, the authors |  |  |
| retain all their rights. |  |  |
| This document and the information contained herein are provided on an |  |  |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  |  |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  |  |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  |  |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  |  |
| THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |  |  |
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |  |  |
| Intellectual Property |  |  |
| The IETF takes no position regarding the validity or scope of any |  |  |
| Intellectual Property Rights or other rights that might be claimed to |  |  |
| pertain to the implementation or use of the technology described in |  |  |
| this document or the extent to which any license under such rights |  |  |
| might or might not be available; nor does it represent that it has |  |  |
| made any independent effort to identify any such rights. Information |  |  |
| on the procedures with respect to rights in RFC documents can be |  |  |
| found in BCP 78 and BCP 79. |  |  |
| Copies of IPR disclosures made to the IETF Secretariat and any |  |  |
| assurances of licenses to be made available, or the result of an |  |  |
| attempt made to obtain a general license or permission for the use of |  |  |
| such proprietary rights by implementers or users of this |  |  |
| specification can be obtained from the IETF on-line IPR repository at |  |  |
| http://www.ietf.org/ipr. |  |  |
| The IETF invites any interested party to bring to its attention any |  |  |
| copyrights, patents or patent applications, or other proprietary |  |  |
| rights that may cover technology that may be required to implement |  |  |
| this standard. Please address the information to the IETF at |  |  |
| ietf-ipr@ietf.org. |  |  |
End of changes. 71 change blocks.
| 116 lines changed or deleted |  | 204 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/