| draft-ietf-httpbis-p4-conditional-15.txt |  | draft-ietf-httpbis-p4-conditional-16.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: January 12, 2012 J. Mogul |  | Expires: February 25, 2012 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | Adobe |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 11, 2011 |  | August 24, 2011 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-15 |  | draft-ietf-httpbis-p4-conditional-16 |
| 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, hypertext 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. |
| request header fields for indicating conditional requests and the |  |  |
| rules for constructing responses to those requests. |  | Part 4 defines request header fields for indicating conditional |
|  |  | requests and the 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), which is archived at |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.16. |  | The changes in this draft are summarized in Appendix C.17. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on January 12, 2012. |  | This Internet-Draft will expire on February 25, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2011 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 5 |  | skipping to change at page 3, line 5 |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Resource State Metadata (Validators) . . . . . . . . . . . . . 6 |  | 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2.1. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6 |
| 2.1.1. Generation . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.1.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.2. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.2.2. Weak versus Strong . . . . . . . . . . . . . . . . . . 9 |  | 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.2.4. Rules for When to Use Entity-tags and |  | 2.3.3. Example: Entity-tags varying on Content-Negotiated |
| Last-Modified Dates . . . . . . . . . . . . . . . . . 11 |  | Resources . . . . . . . . . . . . . . . . . . . . . . 12 |
| 2.2.5. Example: Entity-tags varying on Content-Negotiated |  | 2.4. Rules for When to Use Entity-tags and Last-Modified |
| Resources . . . . . . . . . . . . . . . . . . . . . . 13 |  | Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |  | 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |
| 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |  | 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |
| 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 |  | 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 17 |
| 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 |  | 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 |
| 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 19 |
| 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19 |  | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 20 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |  | 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 |
| 5.2. Header Field Registration . . . . . . . . . . . . . . . . 20 |  | 5.2. Header Field Registration . . . . . . . . . . . . . . . . 20 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 22 |  | publication) . . . . . . . . . . . . . . . . . . . . 23 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23 |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23 |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24 |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 |  | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 |
| C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 |  | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 |
| C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 |  | C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 |
| C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 |  | C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 25 |
| C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 |  | C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 |
| C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 |  | C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 |
| C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 |  | C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 |
| C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25 |  | C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25 |
| C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 25 |  | C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 26 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 26 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 1. Introduction |  | 1. Introduction |
| This document defines the HTTP/1.1 conditional request mechanisms, |  | This document defines the HTTP/1.1 conditional request mechanisms, |
| including both response metadata that can be used to indicate or |  | including both metadata for indicating/observing changes in resource |
| observe changes to resource state and request header fields that |  | representations and request header fields that specify preconditions |
| specify preconditions to be checked before performing the action |  | on that metadata be checked before performing the request method. |
| given by the request method. Conditional GET requests are the most |  | Conditional GET requests are the most efficient mechanism for HTTP |
| efficient mechanism for HTTP cache updates [Part6]. Conditionals can |  | cache updates [Part6]. Conditionals can also be applied to state- |
| also be applied to state-changing methods, such as PUT and DELETE, to |  | changing methods, such as PUT and DELETE, to prevent the "lost |
| prevent the "lost update" problem: one client accidentally |  | update" problem: one client accidentally overwriting the work of |
| overwriting the work of another client that has been acting in |  | another client that has been acting in parallel. |
| parallel. |  |  |
| Conditional request preconditions are based on the state of the |  | Conditional request preconditions are based on the state of the |
| target resource as a whole (its current value set) or the state as |  | target resource as a whole (its current value set) or the state as |
| observed in a previously obtained representation (one value in that |  | observed in a previously obtained representation (one value in that |
| set). A resource might have multiple current representations, each |  | set). A resource might have multiple current representations, each |
| with its own observable state. The conditional request mechanisms |  | with its own observable state. The conditional request mechanisms |
| assume that the mapping of requests to corresponding representations |  | assume that the mapping of requests to corresponding representations |
| will be consistent over time if the server intends to take advantage |  | will be consistent over time if the server intends to take advantage |
| of conditionals. Regardless, if the mapping is inconsistent and the |  | of conditionals. Regardless, if the mapping is inconsistent and the |
| server is unable to select the appropriate representation, then no |  | server is unable to select the appropriate representation, then no |
| skipping to change at page 6, line 19 |  | skipping to change at page 6, line 19 |
| rule). Appendix B shows the collected ABNF, with the list rule |  | rule). Appendix B shows the collected ABNF, with the list rule |
| expanded. |  | expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (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 |  | 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), |  | sequence of data), SP (space), VCHAR (any visible USASCII character), |
| and WSP (whitespace). |  | and WSP (whitespace). |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in [Part1]: |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  |  |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| 2. Resource State Metadata (Validators) |  | 2. Validators |
| This specification defines two forms of metadata that are commonly |  | This specification defines two forms of metadata that are commonly |
| used to observe resource state and test for preconditions: |  | used to observe resource state and test for preconditions: |
| modification dates and opaque entity tags. Additional metadata that |  | modification dates and opaque entity tags. Additional metadata that |
| reflects resource state has been defined by various extensions of |  | reflects resource state has been defined by various extensions of |
| HTTP, such as WebDAV [RFC4918], that are beyond the scope of this |  | HTTP, such as WebDAV [RFC4918], that are beyond the scope of this |
| specification. A resource metadata value is referred to as a |  | specification. A resource metadata value is referred to as a |
| "validator" when it is used within a precondition. |  | "validator" when it is used within a precondition. |
| 2.1. Last-Modified |  | 2.1. Weak versus Strong |
|  |  | Validators come in two flavors: strong or weak. Weak validators are |
|  |  | easy to generate but are far less useful for comparisons. Strong |
|  |  | validators are ideal for comparisons but can be very difficult (and |
|  |  | occasionally impossible) to generate efficiently. Rather than impose |
|  |  | that all forms of resource adhere to the same strength of validator, |
|  |  | HTTP exposes the type of validator in use and imposes restrictions on |
|  |  | when weak validators can be used as preconditions. |
|  |  | A "strong validator" is a representation metadata value that MUST be |
|  |  | changed to a new, previously unused or guaranteed unique, value |
|  |  | whenever a change occurs to the representation data such that a |
|  |  | change would be observable in the payload body of a 200 response to |
|  |  | GET. A strong validator MAY be changed for other reasons, such as |
|  |  | when a semantically significant part of the representation metadata |
|  |  | is changed (e.g., Content-Type), but it is in the best interests of |
|  |  | the origin server to only change the value when it is necessary to |
|  |  | invalidate the stored responses held by remote caches and authoring |
|  |  | tools. A strong validator MUST be unique across all representations |
|  |  | of a given resource, such that no two representations of that |
|  |  | resource share the same validator unless their payload body would be |
|  |  | identical. |
|  |  | Cache entries might persist for arbitrarily long periods, regardless |
|  |  | of expiration times. Thus, a cache might attempt to validate an |
|  |  | entry using a validator that it obtained in the distant past. A |
|  |  | strong validator MUST be unique across all versions of all |
|  |  | representations associated with a particular resource over time. |
|  |  | However, there is no implication of uniqueness across representations |
|  |  | of different resources (i.e., the same strong validator might be in |
|  |  | use for representations of multiple resources at the same time and |
|  |  | does not imply that those representations are equivalent). |
|  |  | There are a variety of strong validators used in practice. The best |
|  |  | are based on strict revision control, wherein each change to a |
|  |  | representation always results in a unique node name and revision |
|  |  | identifier being assigned before the representation is made |
|  |  | accessible to GET. A cryptographic hash function applied to the |
|  |  | representation data is also sufficient if the data is available prior |
|  |  | to the response header fields being sent and the digest does not need |
|  |  | to be recalculated every time a validation request is received. |
|  |  | However, if a resource has distinct representations that differ only |
|  |  | in their metadata, such as might occur with content negotiation over |
|  |  | media types that happen to share the same data format, then a server |
|  |  | SHOULD incorporate additional information in the validator to |
|  |  | distinguish those representations and avoid confusing cache behavior. |
|  |  | In contrast, a "weak validator" is a representation metadata value |
|  |  | that might not be changed for every change to the representation |
|  |  | data. This weakness might be due to limitations in how the value is |
|  |  | calculated, such as clock resolution or an inability to ensure |
|  |  | uniqueness for all possible representations of the resource, or due |
|  |  | to a desire by the resource owner to group representations by some |
|  |  | self-determined set of equivalency rather than unique sequences of |
|  |  | data. A weak entity-tag SHOULD change whenever the origin server |
|  |  | considers prior representations to be unacceptable as a substitute |
|  |  | for the current representation. In other words, a weak entity-tag |
|  |  | SHOULD change whenever the origin server wants caches to invalidate |
|  |  | old responses. |
|  |  | For example, the representation of a weather report that changes in |
|  |  | content every second, based on dynamic measurements, might be grouped |
|  |  | into sets of equivalent representations (from the origin server's |
|  |  | perspective) with the same weak validator in order to allow cached |
|  |  | representations to be valid for a reasonable period of time (perhaps |
|  |  | adjusted dynamically based on server load or weather quality). |
|  |  | Likewise, a representation's modification time, if defined with only |
|  |  | one-second resolution, might be a weak validator if it is possible |
|  |  | for the representation to be modified twice during a single second |
|  |  | and retrieved between those modifications. |
|  |  | A "use" of a validator occurs when either a client generates a |
|  |  | request and includes the validator in a precondition or when a server |
|  |  | compares two validators. Weak validators are only usable in contexts |
|  |  | that do not depend on exact equality of a representation's payload |
|  |  | body. Strong validators are usable and preferred for all conditional |
|  |  | requests, including cache validation, partial content ranges, and |
|  |  | "lost update" avoidance. |
|  |  | 2.2. Last-Modified |
| The "Last-Modified" header field indicates the date and time at which |  | The "Last-Modified" header field indicates the date and time at which |
| the origin server believes the selected representation was last |  | the origin server believes the selected representation was last |
| modified. |  | modified. |
| Last-Modified = HTTP-date |  | Last-Modified = 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 |
| 2.1.1. Generation |  | 2.2.1. Generation |
| Origin servers SHOULD send Last-Modified for any selected |  | Origin servers SHOULD send Last-Modified for any selected |
| representation for which a last modification date can be reasonably |  | representation for which a last modification date can be reasonably |
| and consistently determined, since its use in conditional requests |  | and consistently determined, since its use in conditional requests |
| and evaluating cache freshness ([Part6]) results in a substantial |  | and evaluating cache freshness ([Part6]) results in a substantial |
| reduction of HTTP traffic on the Internet and can be a significant |  | reduction of HTTP traffic on the Internet and can be a significant |
| factor in improving service scalability and reliability. |  | factor in improving service scalability and reliability. |
| A representation is typically the sum of many parts behind the |  | A representation is typically the sum of many parts behind the |
| resource interface. The last-modified time would usually be the most |  | resource interface. The last-modified time would usually be the most |
| skipping to change at page 7, line 31 |  | skipping to change at page 9, line 15 |
| response is generated. |  | response is generated. |
| An origin server with a clock MUST NOT send a Last-Modified date that |  | An origin server with a clock MUST NOT send a Last-Modified date that |
| is later than the server's time of message origination (Date). If |  | is later than the server's time of message origination (Date). If |
| the last modification time is derived from implementation-specific |  | the last modification time is derived from implementation-specific |
| metadata that evaluates to some time in the future, according to the |  | metadata that evaluates to some time in the future, according to the |
| origin server's clock, then the origin server MUST replace that value |  | origin server's clock, then the origin server MUST replace that value |
| with the message origination date. This prevents a future |  | with the message origination date. This prevents a future |
| modification date from having an adverse impact on cache validation. |  | modification date from having an adverse impact on cache validation. |
| 2.1.2. Comparison |  | 2.2.2. Comparison |
| 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 representation and, |  | current validator for the representation and, |
| o That origin server reliably knows that the associated |  | o That origin server reliably knows that the associated |
| representation did not change twice during the second covered by |  | representation did not change twice during the second covered by |
| the presented validator. |  | the presented validator. |
| or |  | or |
| o The validator is about to be used by a client in an If-Modified- |  | o The validator is about to be used by a client in an If-Modified- |
| Since or If-Unmodified-Since header field, because the client has |  | Since, If-Unmodified-Since header field, because the client has a |
| a cache entry for the associated representation, and |  | cache entry, or If-Range for the associated representation, and |
| o That cache entry includes a Date value, which gives the time when |  | o That cache entry includes a Date value, which gives the time when |
| the origin server sent the original response, and |  | the origin server sent the original response, and |
| o The presented Last-Modified time is at least 60 seconds before the |  | o The presented Last-Modified time is at least 60 seconds before the |
| Date value. |  | Date value. |
| or |  | or |
| o The validator is being compared by an intermediate cache to the |  | o The validator is being compared by an intermediate cache to the |
| skipping to change at page 8, line 29 |  | skipping to change at page 10, line 13 |
| This method relies on the fact that if two different responses were |  | This method relies on the fact that if two different responses were |
| sent by the origin server during the same second, but both had the |  | sent by the origin server during the same second, but both had the |
| same Last-Modified time, then at least one of those responses would |  | same Last-Modified time, then at least one of those responses would |
| have a Date value equal to its Last-Modified time. The arbitrary 60- |  | have a Date value equal to its Last-Modified time. The arbitrary 60- |
| second limit guards against the possibility that the Date and Last- |  | second limit guards against the possibility that the Date and Last- |
| Modified values are generated from different clocks, or at somewhat |  | Modified values are generated from different clocks, or at somewhat |
| different times during the preparation of the response. An |  | different times during the preparation of the response. An |
| implementation MAY use a value larger than 60 seconds, if it is |  | implementation MAY use a value larger than 60 seconds, if it is |
| believed that 60 seconds is too short. |  | believed that 60 seconds is too short. |
| 2.2. ETag |  | 2.3. ETag |
| The ETag header field provides the current entity-tag for the |  | The ETag header field provides the current entity-tag for the |
| selected representation. An entity-tag is an opaque validator for |  | selected representation. An entity-tag is an opaque validator for |
| differentiating between multiple representations of the same |  | differentiating between multiple representations of the same |
| resource, regardless of whether those multiple representations are |  | resource, regardless of whether those multiple representations are |
| due to resource state changes over time, content negotiation |  | due to resource state changes over time, content negotiation |
| resulting in multiple representations being valid at the same time, |  | resulting in multiple representations being valid at the same time, |
| or both. An entity-tag consists of an opaque quoted string, possibly |  | or both. An entity-tag consists of an opaque quoted string, possibly |
| prefixed by a weakness indicator. |  | prefixed by a weakness indicator. |
| skipping to change at page 9, line 11 |  | skipping to change at page 10, line 42 |
| dates, where the one-second resolution of HTTP date values is not |  | dates, where the one-second resolution of HTTP date values is not |
| sufficient, or where modification dates are not consistently |  | sufficient, or where modification dates are not consistently |
| maintained. |  | maintained. |
| Examples: |  | Examples: |
| ETag: "xyzzy" |  | ETag: "xyzzy" |
| ETag: W/"xyzzy" |  | ETag: W/"xyzzy" |
| ETag: "" |  | ETag: "" |
| 2.2.1. Generation |  | An entity-tag can be either a weak or strong validator, with strong |
|  |  | being the default. If an origin server provides an entity-tag for a |
|  |  | representation and the generation of that entity-tag does not satisfy |
|  |  | the requirements for a strong validator (Section 2.1), then that |
|  |  | entity-tag MUST be marked as weak by prefixing its opaque value with |
|  |  | "W/" (case-sensitive). |
|  |  | 2.3.1. Generation |
| The principle behind entity-tags is that only the service author |  | The principle behind entity-tags is that only the service author |
| knows the implementation of a resource well enough to select the most |  | knows the implementation of a resource well enough to select the most |
| accurate and efficient validation mechanism for that resource, and |  | accurate and efficient validation mechanism for that resource, and |
| that any such mechanism can be mapped to a simple sequence of octets |  | that any such mechanism can be mapped to a simple sequence of octets |
| for easy comparison. Since the value is opaque, there is no need for |  | for easy comparison. Since the value is opaque, there is no need for |
| the client to be aware of how each entity-tag is constructed. |  | the client to be aware of how each entity-tag is constructed. |
| For example, a resource that has implementation-specific versioning |  | For example, a resource that has implementation-specific versioning |
| applied to all changes might use an internal revision number, perhaps |  | applied to all changes might use an internal revision number, perhaps |
| skipping to change at page 9, line 35 |  | skipping to change at page 11, line 29 |
| combination of various filesystem attributes, or a modification |  | combination of various filesystem attributes, or a modification |
| timestamp that has sub-second resolution. |  | timestamp that has sub-second resolution. |
| Origin servers SHOULD send ETag for any selected representation for |  | Origin servers SHOULD send ETag for any selected representation for |
| which detection of changes can be reasonably and consistently |  | which detection of changes can be reasonably and consistently |
| determined, since the entity-tag's use in conditional requests and |  | determined, since the entity-tag's use in conditional requests and |
| evaluating cache freshness ([Part6]) can result in a substantial |  | evaluating cache freshness ([Part6]) can result in a substantial |
| reduction of HTTP network traffic and can be a significant factor in |  | reduction of HTTP network traffic and can be a significant factor in |
| improving service scalability and reliability. |  | improving service scalability and reliability. |
| 2.2.2. Weak versus Strong |  | 2.3.2. Comparison |
| Since both origin servers and caches will compare two validators to |  |  |
| decide if they indicate the same or different representations, one |  |  |
| normally would expect that if the representation (including both |  |  |
| representation header fields and representation body) changes in any |  |  |
| way, then the associated validator would change as well. If this is |  |  |
| true, then we call that validator a "strong validator". One example |  |  |
| of a strong validator is an integer that is incremented in stable |  |  |
| storage every time a representation is changed. |  |  |
| However, there might be cases when a server prefers to change the |  |  |
| validator only when it desires cached representations to be |  |  |
| invalidated. For example, the representation of a weather report |  |  |
| that changes in content every second, based on dynamic measurements, |  |  |
| might be grouped into sets of equivalent representations (from the |  |  |
| origin server's perspective) in order to allow cached representations |  |  |
| to be valid for a reasonable period of time (perhaps adjusted |  |  |
| dynamically based on server load or weather quality). A validator |  |  |
| that does not always change when the representation changes is a |  |  |
| "weak validator". |  |  |
| One can think of a strong validator as part of an identifier for a |  |  |
| specific representation, whereas a weak validator is part of an |  |  |
| identifier for a set of equivalent representations (where this notion |  |  |
| of equivalence is entirely governed by the origin server and beyond |  |  |
| the scope of this specification). |  |  |
| An entity-tag is normally a strong validator, but the protocol |  |  |
| provides a mechanism to tag an entity-tag as "weak". |  |  |
| A representation's modification time, if defined with only one- |  |  |
| second resolution, could be a weak validator, since it is possible |  |  |
| that the representation might be modified twice during a single |  |  |
| second. |  |  |
| Support for weak validators is optional. However, weak validators |  |  |
| allow for more efficient caching of equivalent objects; for |  |  |
| example, a hit counter on a site is probably good enough if it is |  |  |
| updated every few days or weeks, and any value during that period |  |  |
| is likely "good enough" to be equivalent. |  |  |
| A strong entity-tag MUST change whenever the associated |  |  |
| representation changes in any way. A weak entity-tag SHOULD change |  |  |
| whenever the origin server considers prior representations to be |  |  |
| unacceptable as a substitute for the current representation. In |  |  |
| other words, a weak entity tag SHOULD change whenever the origin |  |  |
| server wants caches to invalidate old responses. |  |  |
| A "strong entity-tag" MAY be shared by two representations of a |  |  |
| resource only if they are equivalent by octet equality. |  |  |
| A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by |  |  |
| two representations of a resource. A weak entity-tag can only be |  |  |
| used for weak comparison. |  |  |
| Cache entries might persist for arbitrarily long periods, regardless |  |  |
| of expiration times. Thus, a cache might attempt to validate an |  |  |
| entry using a validator that it obtained in the distant past. A |  |  |
| strong entity-tag MUST be unique across all versions of all |  |  |
| representations associated with a particular resource over time. |  |  |
| However, there is no implication of uniqueness across entity-tags of |  |  |
| different resources (i.e., the same entity-tag value might be in use |  |  |
| for representations of multiple resources at the same time and does |  |  |
| not imply that those representations are equivalent). |  |  |
| 2.2.3. Comparison |  |  |
| There are two entity-tag comparison functions, depending on whether |  | There are two entity-tag comparison functions, depending on whether |
| the comparison context allows the use of weak validators or not: |  | the comparison context allows the use of weak validators or not: |
| o The strong comparison function: in order to be considered equal, |  | o The strong comparison function: in order to be considered equal, |
| both opaque-tags MUST be identical character-by-character, and |  | both opaque-tags MUST be identical character-by-character, and |
| both MUST NOT be weak. |  | both MUST NOT be weak. |
| o The weak comparison function: in order to be considered equal, |  | o The weak comparison function: in order to be considered equal, |
| both opaque-tags MUST be identical character-by-character, but |  | both opaque-tags MUST be identical character-by-character, but |
| either or both of them MAY be tagged as "weak" without affecting |  | either or both of them MAY be tagged as "weak" without affecting |
| the result. |  | the result. |
| A "use" of a validator is either when a client generates a request |  |  |
| and includes the validator in a precondition, or when a server |  |  |
| compares two validators. |  |  |
| Strong validators are usable in any context. Weak validators are |  |  |
| only usable in contexts that do not depend on exact equality of a |  |  |
| representation. For example, either kind is usable for a normal |  |  |
| conditional GET. |  |  |
| The example below shows the results for a set of entity-tag pairs, |  | The example below shows the results for a set of entity-tag pairs, |
| and both the weak and strong comparison function results: |  | and both the weak and strong comparison function results: |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | |  | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| | W/"1" | W/"1" | no match | match | |  | | W/"1" | W/"1" | no match | match | |
| | W/"1" | W/"2" | no match | no match | |  | | W/"1" | W/"2" | no match | no match | |
| | W/"1" | "1" | no match | match | |  | | W/"1" | "1" | no match | match | |
| | "1" | "1" | match | match | |  | | "1" | "1" | match | match | |
| +--------+--------+-------------------+-----------------+ |  | +--------+--------+-------------------+-----------------+ |
| An entity-tag is strong unless it is explicitly tagged as weak. |  | 2.3.3. Example: Entity-tags varying on Content-Negotiated Resources |
| 2.2.4. Rules for When to Use Entity-tags and Last-Modified Dates |  | Consider a resource that is subject to content negotiation (Section 5 |
|  |  | of [Part3]), and where the representations returned upon a GET |
|  |  | request vary based on the Accept-Encoding request header field |
|  |  | (Section 6.3 of [Part3]): |
|  |  | >> Request: |
|  |  | GET /index HTTP/1.1 |
|  |  | Host: www.example.com |
|  |  | Accept-Encoding: gzip |
|  |  | In this case, the response might or might not use the gzip content |
|  |  | coding. If it does not, the response might look like: |
|  |  | >> Response: |
|  |  | HTTP/1.1 200 OK |
|  |  | Date: Thu, 26 Mar 2010 00:05:00 GMT |
|  |  | ETag: "123-a" |
|  |  | Content-Length: 70 |
|  |  | Vary: Accept-Encoding |
|  |  | Content-Type: text/plain |
|  |  | Hello World! |
|  |  | Hello World! |
|  |  | Hello World! |
|  |  | Hello World! |
|  |  | Hello World! |
|  |  | An alternative representation that does use gzip content coding would |
|  |  | be: |
|  |  | >> Response: |
|  |  | HTTP/1.1 200 OK |
|  |  | Date: Thu, 26 Mar 2010 00:05:00 GMT |
|  |  | ETag: "123-b" |
|  |  | Content-Length: 43 |
|  |  | Vary: Accept-Encoding |
|  |  | Content-Type: text/plain |
|  |  | Content-Encoding: gzip |
|  |  | ...binary data... |
|  |  | Note: Content codings are a property of the representation, so |
|  |  | therefore an entity-tag of an encoded representation must be |
|  |  | distinct from an unencoded representation to prevent conflicts |
|  |  | during cache updates and range requests. In contrast, transfer |
|  |  | codings (Section 6.2 of [Part1]) apply only during message |
|  |  | transfer and do not require distinct entity-tags. |
|  |  | 2.4. 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 13, line 13 |  | skipping to change at page 14, line 43 |
| conservative assumptions about the validators they receive. |  | conservative assumptions about the validators they receive. |
| HTTP/1.0 clients and caches might ignore entity-tags. Generally, |  | HTTP/1.0 clients and caches might 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. |
| 2.2.5. Example: Entity-tags varying on Content-Negotiated Resources |  |  |
| Consider a resource that is subject to content negotiation (Section 5 |  |  |
| of [Part3]), and where the representations returned upon a GET |  |  |
| request vary based on the Accept-Encoding request header field |  |  |
| (Section 6.3 of [Part3]): |  |  |
| >> Request: |  |  |
| GET /index HTTP/1.1 |  |  |
| Host: www.example.com |  |  |
| Accept-Encoding: gzip |  |  |
| In this case, the response might or might not use the gzip content |  |  |
| coding. If it does not, the response might look like: |  |  |
| >> Response: |  |  |
| HTTP/1.1 200 OK |  |  |
| Date: Thu, 26 Mar 2010 00:05:00 GMT |  |  |
| ETag: "123-a" |  |  |
| Content-Length: 70 |  |  |
| Vary: Accept-Encoding |  |  |
| Content-Type: text/plain |  |  |
| Hello World! |  |  |
| Hello World! |  |  |
| Hello World! |  |  |
| Hello World! |  |  |
| Hello World! |  |  |
| An alternative representation that does use gzip content coding would |  |  |
| be: |  |  |
| >> Response: |  |  |
| HTTP/1.1 200 OK |  |  |
| Date: Thu, 26 Mar 2010 00:05:00 GMT |  |  |
| ETag: "123-b" |  |  |
| Content-Length: 43 |  |  |
| Vary: Accept-Encoding |  |  |
| Content-Type: text/plain |  |  |
| Content-Encoding: gzip |  |  |
| ...binary data... |  |  |
| Note: Content codings are a property of the representation, so |  |  |
| therefore an entity-tag of an encoded representation must be |  |  |
| distinct from an unencoded representation to prevent conflicts |  |  |
| during cache updates and range requests. In contrast, transfer |  |  |
| codings (Section 6.2 of [Part1]) apply only during message |  |  |
| transfer and do not require distinct entity-tags. |  |  |
| 3. Precondition Header Fields |  | 3. Precondition Header Fields |
| 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 for applying preconditions on requests. |  | fields for applying preconditions on requests. |
| 3.1. If-Match |  | 3.1. If-Match |
| The "If-Match" header field MAY be used to make a request method |  | The "If-Match" header field MAY be used to make a request method |
| conditional on the current existence or value of an entity-tag for |  | conditional on the current existence or value of an entity-tag for |
| one or more representations of the target resource. If-Match is |  | one or more representations of the target resource. If-Match is |
| generally useful for resource update requests, such as PUT requests, |  | generally useful for resource update requests, such as PUT requests, |
| as a means for protecting against accidental overwrites when multiple |  | as a means for protecting against accidental overwrites when multiple |
| clients are acting in parallel on the same resource (i.e., the "lost |  | clients are acting in parallel on the same resource (i.e., the "lost |
| update" problem). An If-Match field-value of "*" places the |  | update" problem). An If-Match field-value of "*" places the |
| precondition on the existence of any current representation for the |  | precondition on the existence of any current representation for the |
| target resource. |  | target resource. |
| If-Match = "*" / 1#entity-tag |  | If-Match = "*" / 1#entity-tag |
| If any of the entity-tags listed in the If-Match field value match |  | If any of the entity-tags listed in the If-Match field value match |
| (as per Section 2.2.3) the entity-tag of the selected representation |  | (as per Section 2.3.2) the entity-tag of the selected representation |
| for the target resource, or if "*" is given and any current |  | for the target resource, or if "*" is given and any current |
| representation exists for the target resource, then the server MAY |  | representation exists for the target resource, then the server MAY |
| perform the request method as if the If-Match header field was not |  | perform the request method as if the If-Match header field was not |
| present. |  | present. |
| If none of the entity-tags match, or if "*" is given and no current |  | If none of the entity-tags match, or if "*" is given and no current |
| representation exists, the server MUST NOT perform the requested |  | representation exists, the server MUST NOT perform the requested |
| method. Instead, the server MUST respond with the 412 (Precondition |  | method. Instead, the server MUST respond with the 412 (Precondition |
| Failed) status code. |  | Failed) status code. |
| skipping to change at page 15, line 44 |  | skipping to change at page 16, line 16 |
| unsafe request method (e.g., PUT) from inadvertently modifying an |  | unsafe request method (e.g., PUT) from inadvertently modifying an |
| existing representation of the target resource when the client |  | existing representation of the target resource when the client |
| believes that the resource does not have a current representation. |  | believes that the resource does not have a current representation. |
| This is a variation on the "lost update" problem that might arise if |  | This is a variation on the "lost update" problem that might arise if |
| more than one client attempts to create an initial representation for |  | more than one client attempts to create an initial representation for |
| the target resource. |  | the target resource. |
| If-None-Match = "*" / 1#entity-tag |  | If-None-Match = "*" / 1#entity-tag |
| If any of the entity-tags listed in the If-None-Match field-value |  | If any of the entity-tags listed in the If-None-Match field-value |
| match (as per Section 2.2.3) the entity-tag of the selected |  | match (as per Section 2.3.2) the entity-tag of the selected |
| representation, or if "*" is given and any current representation |  | representation, or if "*" is given and any current representation |
| exists for that resource, then the server MUST NOT perform the |  | exists for that resource, then the server MUST NOT perform the |
| requested method. Instead, if the request method was GET or HEAD, |  | requested method. Instead, if the request method was GET or HEAD, |
| the server SHOULD respond with a 304 (Not Modified) status code, |  | the server SHOULD respond with a 304 (Not Modified) status code, |
| including the cache-related header fields (particularly ETag) of the |  | including the cache-related header fields (particularly ETag) of the |
| selected representation that has a matching entity-tag. For all |  | selected representation that has a matching entity-tag. For all |
| other request methods, the server MUST respond with a 412 |  | other request methods, the server MUST respond with a 412 |
| (Precondition Failed) status code. |  | (Precondition Failed) status code. |
| If none of the entity-tags match, then the server MAY perform the |  | If none of the entity-tags match, then the server MAY perform the |
| requested method as if the If-None-Match header field did not exist, |  | requested method as if the If-None-Match header field did not exist, |
| but MUST also ignore any If-Modified-Since header field(s) in the |  | but MUST also ignore any If-Modified-Since header field(s) in the |
| request. That is, if no entity-tags match, then the server MUST NOT |  | request. That is, if no entity-tags match, then the server MUST NOT |
| return a 304 (Not Modified) response. |  | return a 304 (Not Modified) response. |
| If the request would, without the If-None-Match header field, result |  | If the request would, without the If-None-Match header field, result |
| in anything other than a 2xx or 304 status code, then the If-None- |  | in anything other than a 2xx or 304 status code, then the If-None- |
| Match header field MUST be ignored. (See Section 2.2.4 for a |  | Match header field MUST be ignored. (See Section 2.4 for a |
| discussion of server behavior when both If-Modified-Since and If- |  | discussion of server behavior when both If-Modified-Since and If- |
| None-Match appear in the same request.) |  | None-Match appear in the same request.) |
| 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: * |
| skipping to change at page 20, line 21 |  | skipping to change at page 20, line 38 |
| 5.2. Header Field Registration |  | 5.2. Header Field Registration |
| The Message Header Field Registry located at <http://www.iana.org/ |  | The Message Header Field Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> shall be |  | assignments/message-headers/message-header-index.html> shall 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 2.2 | |  | | ETag | http | standard | Section 2.3 | |
| | If-Match | http | standard | Section 3.1 | |  | | If-Match | http | standard | Section 3.1 | |
| | If-Modified-Since | http | standard | Section 3.3 | |  | | If-Modified-Since | http | standard | Section 3.3 | |
| | If-None-Match | http | standard | Section 3.2 | |  | | If-None-Match | http | standard | Section 3.2 | |
| | If-Unmodified-Since | http | standard | Section 3.4 | |  | | If-Unmodified-Since | http | standard | Section 3.4 | |
| | Last-Modified | http | standard | Section 2.1 | |  | | Last-Modified | http | standard | Section 2.2 | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 6. Security Considerations |  | 6. 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]. |
| 7. Acknowledgments |  | 7. Acknowledgments |
|  |  | See Section 12 of [Part1]. |
| 8. References |  | 8. References |
| 8.1. Normative References |  | 8.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-15 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-16 |
| (work in progress), July 2011. |  | (work in progress), August 2011. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-15 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-16 |
| (work in progress), July 2011. |  | (work in progress), August 2011. |
| [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-15 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-16 (work |
| in progress), July 2011. |  | in progress), August 2011. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-15 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-16 (work in |
| progress), July 2011. |  | progress), August 2011. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 8.2. Informative References |  | 8.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| skipping to change at page 21, line 40 |  | skipping to change at page 22, line 11 |
| [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. |
| [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed |  | [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed |
| Authoring and Versioning (WebDAV)", RFC 4918, June 2007. |  | Authoring and Versioning (WebDAV)", RFC 4918, June 2007. |
| Appendix A. Changes from RFC 2616 |  | Appendix A. 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 2.2.2 and 3.2). |  | (Sections 2.1 and 3.2). |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 3) |  | value. (Section 3) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| ETag = entity-tag |  | ETag = entity-tag |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| skipping to change at page 22, line 26 |  | skipping to change at page 22, line 37 |
| If-Unmodified-Since = HTTP-date |  | If-Unmodified-Since = HTTP-date |
| Last-Modified = HTTP-date |  | Last-Modified = HTTP-date |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| entity-tag = [ weak ] opaque-tag |  | entity-tag = [ weak ] opaque-tag |
| opaque-tag = quoted-string |  | opaque-tag = quoted-string |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
| weak = %x57.2F ; W/ |  | weak = %x57.2F ; W/ |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; ETag defined but not used |  | ; ETag defined but not used |
| ; If-Match defined but not used |  | ; If-Match defined but not used |
| ; If-Modified-Since defined but not used |  | ; If-Modified-Since defined but not used |
| ; If-None-Match defined but not used |  | ; If-None-Match defined but not used |
| ; If-Unmodified-Since defined but not used |  | ; If-Unmodified-Since defined but not used |
| skipping to change at page 25, line 36 |  | skipping to change at page 26, line 9 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/269>: "ETags and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/269>: "ETags and |
| Quotes" |  | Quotes" |
| C.16. Since draft-ietf-httpbis-p4-conditional-14 |  | C.16. Since draft-ietf-httpbis-p4-conditional-14 |
| None. |  | None. |
|  |  | C.17. Since draft-ietf-httpbis-p4-conditional-15 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/304>: "If-Range |
|  |  | should be listed when dicussing contexts where L-M can be |
|  |  | considered strong" |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 18 |  | 304 Not Modified (status code) 19 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 19 |  | 412 Precondition Failed (status code) 20 |
| E |  | E |
| ETag header field 8 |  | ETag header field 10 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 8 |  | entity-tag 10 |
| ETag 8 |  | ETag 10 |
| If-Match 14 |  | If-Match 15 |
| If-Modified-Since 16 |  | If-Modified-Since 17 |
| If-None-Match 15 |  | If-None-Match 16 |
| If-Unmodified-Since 18 |  | If-Unmodified-Since 18 |
| Last-Modified 6 |  | Last-Modified 8 |
| opaque-tag 8 |  | opaque-tag 10 |
| weak 8 |  | weak 10 |
| H |  | H |
| Header Fields |  | Header Fields |
| ETag 8 |  | ETag 10 |
| If-Match 14 |  | If-Match 14 |
| If-Modified-Since 16 |  | If-Modified-Since 17 |
| If-None-Match 15 |  | If-None-Match 15 |
| If-Unmodified-Since 18 |  | If-Unmodified-Since 18 |
| Last-Modified 6 |  | Last-Modified 8 |
| I |  | I |
| If-Match header field 14 |  | If-Match header field 14 |
| If-Modified-Since header field 16 |  | If-Modified-Since header field 17 |
| If-None-Match header field 15 |  | If-None-Match header field 15 |
| If-Unmodified-Since header field 18 |  | If-Unmodified-Since header field 18 |
| L |  | L |
| Last-Modified header field 6 |  | Last-Modified header field 8 |
| M |  | M |
| metadata 6 |  | metadata 6 |
| S |  | S |
| selected representation 5 |  | selected representation 5 |
| Status Codes |  | Status Codes |
| 304 Not Modified 18 |  | 304 Not Modified 19 |
| 412 Precondition Failed 19 |  | 412 Precondition Failed 20 |
| V |  | V |
| validator 6 |  | validator 6 |
|  |  | strong 6 |
|  |  | weak 6 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 57 change blocks.
| 223 lines changed or deleted |  | 246 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/