| draft-ietf-httpbis-p4-conditional-13.txt |  | draft-ietf-httpbis-p4-conditional-14.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: September 15, 2011 J. Mogul |  | Expires: October 20, 2011 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 |
| March 14, 2011 |  | April 18, 2011 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-13 |  | draft-ietf-httpbis-p4-conditional-14 |
| 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), which is archived at |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
|  |  | The current issues list is at |
|  |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.14. |  | The changes in this draft are summarized in Appendix C.15. |
| 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 September 15, 2011. |  | This Internet-Draft will expire on October 20, 2011. |
| 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 9 |  | skipping to change at page 3, line 4 |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2. Resource State Metadata (Validators) . . . . . . . . . . . . . 6 |
| 1.2.2. ABNF Rules defined in other Parts of the |  | 2.1. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 6 |
| Specification . . . . . . . . . . . . . . . . . . . . 6 |  | 2.1.1. Generation . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2.1.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Example: Entity-tags varying on Content-Negotiated |  | 2.2. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| Resources . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 9 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 8 |  | 2.2.2. Weak versus Strong . . . . . . . . . . . . . . . . . . 9 |
| 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 |
| 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8 |  | 2.2.4. Rules for When to Use Entity-tags and |
| 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 9 |  | Last-Modified Dates . . . . . . . . . . . . . . . . . 11 |
| 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 11 |  | 2.2.5. Example: Entity-tags varying on Content-Negotiated |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 13 |  | Resources . . . . . . . . . . . . . . . . . . . . . . 13 |
| 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 |
| 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 |  | 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 |
| 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 17 |  | 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 |
| 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 |  | 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 |
| 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 19 |  | 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |
| 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 |
| 7.2. Header Field Registration . . . . . . . . . . . . . . . . 20 |  | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 5.2. Header Field Registration . . . . . . . . . . . . . . . . 20 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 |
|  |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
|  |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 |
|  |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 |
| 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) . . . . . . . . . . . . . . . . . . . . 22 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 |
| 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 . . . . . . . . 24 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 |
| 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 . . . . . . . . 24 |
| C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 |  | C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 |
| 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 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 response metadata for indicating |  | This document defines the HTTP/1.1 conditional request mechanisms, |
| potential changes to payload content, including modification time |  | including both response metadata that can be used to indicate or |
| stamps and opaque entity-tags, and the HTTP conditional request |  | observe changes to resource state and request header fields that |
| mechanisms that allow preconditions to be placed on a request method. |  | specify preconditions to be checked before performing the action |
| Conditional GET requests allow for efficient cache updates. Other |  | given by the request method. Conditional GET requests are the most |
| conditional request methods are used to protect against overwriting |  | efficient mechanism for HTTP cache updates [Part6]. Conditionals can |
| or misunderstanding the state of a resource that has been changed |  | also be applied to state-changing methods, such as PUT and DELETE, to |
| unbeknownst to the requesting client. |  | prevent the "lost update" problem: one client accidentally |
|  |  | overwriting the work of another client that has been acting in |
|  |  | parallel. |
| This document is currently disorganized in order to minimize the |  | Conditional request preconditions are based on the state of the |
| changes between drafts and enable reviewers to see the smaller errata |  | target resource as a whole (its current value set) or the state as |
| changes. A future draft will reorganize the sections to better |  | observed in a previously obtained representation (one value in that |
| reflect the content. In particular, the sections on resource |  | set). A resource might have multiple current representations, each |
| metadata will be discussed first and then followed by each |  | with its own observable state. The conditional request mechanisms |
| conditional request header field, concluding with a definition of |  | assume that the mapping of requests to corresponding representations |
| precedence and the expectation of ordering strong validator checks |  | will be consistent over time if the server intends to take advantage |
| before weak validator checks. It is likely that more content from |  | of conditionals. Regardless, if the mapping is inconsistent and the |
| [Part6] will migrate to this part, where appropriate. The current |  | server is unable to select the appropriate representation, then no |
| mess reflects how widely dispersed these topics and associated |  | harm will result when the precondition evaluates to false. |
| requirements had become in [RFC2616]. |  |  |
|  |  | We use the term "selected representation" to refer to the current |
|  |  | representation of the target resource that would have been selected |
|  |  | in a successful response if the same request had used the method GET |
|  |  | and had excluded all of the conditional request header fields. The |
|  |  | conditional request preconditions are evaluated by comparing the |
|  |  | values provided in the request header fields to the current metadata |
|  |  | for the selected representation. |
| 1.1. Requirements |  | 1.1. Requirements |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| 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 |
| skipping to change at page 6, line 8 |  | 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). |
| 1.2.1. Core Rules |  | The ABNF rules below are defined in other parts: |
| The core rules below are defined in Section 1.2.2 of [Part1]: |  |  |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
|  |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| 1.2.2. ABNF Rules defined in other Parts of the Specification |  | 2. Resource State Metadata (Validators) |
| The ABNF rules below are defined in other parts: |  | This specification defines two forms of metadata that are commonly |
|  |  | used to observe resource state and test for preconditions: |
|  |  | modification dates and opaque entity tags. Additional metadata that |
|  |  | reflects resource state has been defined by various extensions of |
|  |  | HTTP, such as WebDAV [RFC4918], that are beyond the scope of this |
|  |  | specification. A resource metadata value is referred to as a |
|  |  | "validator" when it is used within a precondition. |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | 2.1. Last-Modified |
| 2. Entity-Tags |  | The "Last-Modified" header field indicates the date and time at which |
|  |  | the origin server believes the selected representation was last |
|  |  | modified. |
| Entity-tags are used for comparing two or more representations of the |  | Last-Modified = HTTP-date |
| same resource. HTTP/1.1 uses entity-tags in the ETag (Section 6.1), |  |  |
| If-Match (Section 6.2), If-None-Match (Section 6.4), and If-Range |  |  |
| (Section 5.3 of [Part5]) header fields. The definition of how they |  |  |
| are used and compared as cache validators is in Section 4. An |  |  |
| entity-tag consists of an opaque quoted string, possibly prefixed by |  |  |
| a weakness indicator. |  |  |
| entity-tag = [ weak ] opaque-tag |  | An example of its use is |
| weak = %x57.2F ; "W/", case-sensitive |  |  |
| opaque-tag = quoted-string |  |  |
| A "strong entity-tag" MAY be shared by two representations of a |  | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| resource only if they are equivalent by octet equality. |  |  |
| A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by |  | 2.1.1. Generation |
| two representations of a resource only if the representations are |  |  |
| equivalent and could be substituted for each other with no |  |  |
| significant change in semantics. A weak entity-tag can only be used |  |  |
| for weak comparison. |  |  |
| An entity-tag MUST be unique across all versions of all |  | Origin servers SHOULD send Last-Modified for any selected |
| representations associated with a particular resource. A given |  | representation for which a last modification date can be reasonably |
| entity-tag value MAY be used for representations obtained by requests |  | and consistently determined, since its use in conditional requests |
| on different URIs. The use of the same entity-tag value in |  | and evaluating cache freshness ([Part6]) results in a substantial |
| conjunction with representations obtained by requests on different |  | reduction of HTTP traffic on the Internet and can be a significant |
| URIs does not imply the equivalence of those representations. |  | factor in improving service scalability and reliability. |
| 2.1. Example: Entity-tags varying on Content-Negotiated Resources |  | A representation is typically the sum of many parts behind the |
|  |  | resource interface. The last-modified time would usually be the most |
|  |  | recent time that any of those parts were changed. How that value is |
|  |  | determined for any given resource is an implementation detail beyond |
|  |  | the scope of this specification. What matters to HTTP is how |
|  |  | recipients of the Last-Modified header field can use its value to |
|  |  | make conditional requests and test the validity of locally cached |
|  |  | responses. |
| Consider a resource that is subject to content negotiation (Section 5 |  | An origin server SHOULD obtain the Last-Modified value of the |
| of [Part3]), and where the representations returned upon a GET |  | representation as close as possible to the time that it generates the |
| request vary based on the Accept-Encoding request header field |  | Date field-value for its response. This allows a recipient to make |
| (Section 6.3 of [Part3]): |  | an accurate assessment of the representation's modification time, |
|  |  | especially if the representation changes near the time that the |
|  |  | response is generated. |
| >> Request: |  | 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 |
|  |  | the last modification time is derived from implementation-specific |
|  |  | metadata that evaluates to some time in the future, according to the |
|  |  | origin server's clock, then the origin server MUST replace that value |
|  |  | with the message origination date. This prevents a future |
|  |  | modification date from having an adverse impact on cache validation. |
| GET /index HTTP/1.1 |  | 2.1.2. Comparison |
| Host: www.example.com |  |  |
| Accept-Encoding: gzip |  |  |
| In this case, the response might or might not use the gzip content |  | A Last-Modified time, when used as a validator in a request, is |
| coding. If it does not, the response might look like: |  | implicitly weak unless it is possible to deduce that it is strong, |
|  |  | using the following rules: |
| >> Response: |  | o The validator is being compared by an origin server to the actual |
|  |  | current validator for the representation and, |
| HTTP/1.1 200 OK |  | o That origin server reliably knows that the associated |
| Date: Thu, 26 Mar 2010 00:05:00 GMT |  | representation did not change twice during the second covered by |
| ETag: "123-a" |  | the presented validator. |
| Content-Length: 70 |  |  |
| Vary: Accept-Encoding |  |  |
| Content-Type: text/plain |  |  |
| Hello World! |  | or |
| Hello World! |  |  |
| Hello World! |  |  |
| Hello World! |  |  |
| Hello World! |  |  |
| An alternative representation that does use gzip content coding would |  | o The validator is about to be used by a client in an If-Modified- |
| be: |  | Since or If-Unmodified-Since header field, because the client has |
|  |  | a cache entry for the associated representation, and |
| >> Response: |  | o That cache entry includes a Date value, which gives the time when |
|  |  | the origin server sent the original response, and |
| HTTP/1.1 200 OK |  | o The presented Last-Modified time is at least 60 seconds before the |
| Date: Thu, 26 Mar 2010 00:05:00 GMT |  | Date value. |
| ETag: "123-b" |  |  |
| Content-Length: 43 |  |  |
| Vary: Accept-Encoding |  |  |
| Content-Type: text/plain |  |  |
| Content-Encoding: gzip |  |  |
| ...binary data... |  | or |
| Note: Content codings are a property of the representation, so |  | o The validator is being compared by an intermediate cache to the |
| therefore an entity-tag of an encoded representation must be |  | validator stored in its cache entry for the representation, and |
| 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. Status Code Definitions |  | o That cache entry includes a Date value, which gives the time when |
|  |  | the origin server sent the original response, and |
| 3.1. 304 Not Modified |  | o The presented Last-Modified time is at least 60 seconds before the |
|  |  | Date value. |
| If the client has performed a conditional GET request and access is |  | This method relies on the fact that if two different responses were |
| allowed, but the document has not been modified, the server SHOULD |  | sent by the origin server during the same second, but both had the |
| respond with this status code. The 304 response MUST NOT contain a |  | same Last-Modified time, then at least one of those responses would |
| message-body, and thus is always terminated by the first empty line |  | have a Date value equal to its Last-Modified time. The arbitrary 60- |
| after the header fields. |  | second limit guards against the possibility that the Date and Last- |
|  |  | Modified values are generated from different clocks, or at somewhat |
|  |  | different times during the preparation of the response. An |
|  |  | implementation MAY use a value larger than 60 seconds, if it is |
|  |  | believed that 60 seconds is too short. |
| A 304 response MUST include a Date header field (Section 9.3 of |  | 2.2. ETag |
| [Part1]) unless its omission is required by Section 9.3.1 of [Part1]. |  |  |
| If a 200 response to the same request would have included any of the |  |  |
| header fields Cache-Control, Content-Location, ETag, Expires, Last- |  |  |
| Modified, or Vary, then those same header fields MUST be sent in a |  |  |
| 304 response. |  |  |
| Since the goal of a 304 response is to minimize information transfer |  | The ETag header field provides the current entity-tag for the |
| when the recipient already has one or more cached representations, |  | selected representation. An entity-tag is an opaque validator for |
| the response SHOULD NOT include representation metadata other than |  | differentiating between multiple representations of the same |
| the above listed fields unless said metadata exists for the purpose |  | resource, regardless of whether those multiple representations are |
| of guiding cache updates (e.g., future HTTP extensions). |  | due to resource state changes over time, content negotiation |
|  |  | resulting in multiple representations being valid at the same time, |
|  |  | or both. An entity-tag consists of an opaque quoted string, possibly |
|  |  | prefixed by a weakness indicator. |
| If a 304 response includes an entity-tag that indicates a |  | ETag = entity-tag |
| representation not currently cached, then the recipient MUST NOT use |  |  |
| the 304 to update its own cache. If that conditional request |  |  |
| originated with an outbound client, such as a user agent with its own |  |  |
| cache sending a conditional GET to a shared proxy, then the 304 |  |  |
| response MAY be forwarded to the outbound client. Otherwise, |  |  |
| disregard the response and repeat the request without the |  |  |
| conditional. |  |  |
| If a cache uses a received 304 response to update a cache entry, the |  | entity-tag = [ weak ] opaque-tag |
| cache MUST update the entry to reflect any new field values given in |  | weak = %x57.2F ; "W/", case-sensitive |
| the response. |  | opaque-tag = quoted-string |
| 3.2. 412 Precondition Failed |  | An entity-tag can be more reliable for validation than a modification |
|  |  | date in situations where it is inconvenient to store modification |
|  |  | dates, where the one-second resolution of HTTP date values is not |
|  |  | sufficient, or where modification dates are not consistently |
|  |  | maintained. |
| The precondition given in one or more of the header fields evaluated |  | Examples: |
| to false when it was tested on the server. This response code allows |  |  |
| the client to place preconditions on the current resource metadata |  |  |
| (header field data) and thus prevent the requested method from being |  |  |
| applied to a resource other than the one intended. |  |  |
| 4. Weak and Strong Validators |  | ETag: "xyzzy" |
|  |  | ETag: W/"xyzzy" |
|  |  | ETag: "" |
|  |  | 2.2.1. Generation |
|  |  | The principle behind entity-tags is that only the service author |
|  |  | knows the implementation of a resource well enough to select the most |
|  |  | accurate and efficient validation mechanism for that resource, and |
|  |  | 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 |
|  |  | the client to be aware of how each entity-tag is constructed. |
|  |  | For example, a resource that has implementation-specific versioning |
|  |  | applied to all changes might use an internal revision number, perhaps |
|  |  | combined with a variance identifier for content negotiation, to |
|  |  | accurately differentiate between representations. Other |
|  |  | implementations might use a stored hash of representation content, a |
|  |  | combination of various filesystem attributes, or a modification |
|  |  | timestamp that has sub-second resolution. |
|  |  | Origin servers SHOULD send ETag for any selected representation for |
|  |  | which detection of changes can be reasonably and consistently |
|  |  | determined, since the entity-tag's use in conditional requests and |
|  |  | evaluating cache freshness ([Part6]) can result in a substantial |
|  |  | reduction of HTTP network traffic and can be a significant factor in |
|  |  | improving service scalability and reliability. |
|  |  | 2.2.2. Weak versus Strong |
| 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 representations, one |  | decide if they indicate the same or different representations, one |
| normally would expect that if the representation (including both |  | normally would expect that if the representation (including both |
| representation header fields and representation body) changes in any |  | representation header fields and representation body) changes in any |
| way, then the associated validator would change as well. If this is |  | way, then the associated validator would change as well. If this is |
| true, then we call this validator a "strong validator". |  | 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 |  | However, there might be cases when a server prefers to change the |
| validator only on semantically significant changes, and not when |  | validator only when it desires cached representations to be |
| insignificant aspects of the representation change. A validator that |  | invalidated. For example, the representation of a weather report |
| does not always change when the representation changes is a "weak |  | that changes in content every second, based on dynamic measurements, |
| validator". |  | 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". |
| An entity-tag is normally a strong validator, but the protocol |  | One can think of a strong validator as part of an identifier for a |
| provides a mechanism to tag an entity-tag as "weak". One can think |  | specific representation, whereas a weak validator is part of an |
| of a strong validator as one that changes whenever the sequence of |  | identifier for a set of equivalent representations (where this notion |
| bits in a representation changes, while a weak value changes whenever |  | of equivalence is entirely governed by the origin server and beyond |
| the meaning of a representation changes. Alternatively, one can |  | the scope of this specification). |
| 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 semantically equivalent representations. |  |  |
| Note: One example of a strong validator is an integer that is |  | An entity-tag is normally a strong validator, but the protocol |
| incremented in stable storage every time a representation is |  | provides a mechanism to tag an entity-tag as "weak". |
| changed. |  |  |
| A representation's modification time, if defined with only one- |  | A representation's modification time, if defined with only one- |
| second resolution, could be a weak validator, since it is possible |  | second resolution, could be a weak validator, since it is possible |
| that the representation might be modified twice during a single |  | that the representation might be modified twice during a single |
| second. |  | second. |
| Support for weak validators is optional. However, weak validators |  | Support for weak validators is optional. However, weak validators |
| allow for more efficient caching of equivalent objects; for |  | allow for more efficient caching of equivalent objects; for |
| example, a hit counter on a site is probably good enough if it is |  | 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 |  | updated every few days or weeks, and any value during that period |
| is likely "good enough" to be equivalent. |  | is likely "good enough" to be equivalent. |
| A "use" of a validator is either when a client generates a request |  | A strong entity-tag MUST change whenever the associated |
| and includes the validator in a validating header field, or when a |  | representation changes in any way. A weak entity-tag SHOULD change |
| server compares two validators. |  | 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. |
| Strong validators are usable in any context. Weak validators are |  | A "strong entity-tag" MAY be shared by two representations of a |
| only usable in contexts that do not depend on exact equality of a |  | resource only if they are equivalent by octet equality. |
| representation. For example, either kind is usable for a normal |  |  |
| conditional GET. However, only a strong validator is usable for a |  |  |
| sub-range retrieval, since otherwise the client might end up with an |  |  |
| internally inconsistent representation. |  |  |
| Clients MUST NOT use weak validators in range requests ([Part5]). |  | 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. |
| The only function that HTTP/1.1 defines on validators is comparison. |  | Cache entries might persist for arbitrarily long periods, regardless |
| There are two validator comparison functions, depending on whether |  | 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 |
| 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. |  | An entity-tag is strong unless it is explicitly tagged as weak. |
| Section 2 gives the syntax for entity-tags. |  |  |
| A Last-Modified time, when used as a validator in a request, is |  | 2.2.4. Rules for When to Use Entity-tags and Last-Modified Dates |
| implicitly weak unless it is possible to deduce that it is strong, |  |  |
| using the following rules: |  |  |
| o The validator is being compared by an origin server to the actual |  |  |
| current validator for the representation and, |  |  |
| o That origin server reliably knows that the associated |  |  |
| representation did not change twice during the second covered by |  |  |
| the presented validator. |  |  |
| or |  |  |
| 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 |  |  |
| a cache entry for the associated representation, and |  |  |
| o That cache entry includes a Date value, which gives the time when |  |  |
| the origin server sent the original response, and |  |  |
| o The presented Last-Modified time is at least 60 seconds before the |  |  |
| Date value. |  |  |
| or |  |  |
| o The validator is being compared by an intermediate cache to the |  |  |
| validator stored in its cache entry for the representation, and |  |  |
| o That cache entry includes a Date value, which gives the time when |  |  |
| the origin server sent the original response, and |  |  |
| o The presented Last-Modified time is at least 60 seconds before the |  |  |
| Date value. |  |  |
| 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 |  |  |
| 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- |  |  |
| second limit guards against the possibility that the Date and Last- |  |  |
| Modified values are generated from different clocks, or at somewhat |  |  |
| different times during the preparation of the response. An |  |  |
| implementation MAY use a value larger than 60 seconds, if it is |  |  |
| believed that 60 seconds is too short. |  |  |
| If a client wishes to perform a sub-range retrieval on a value for |  |  |
| which it has only a Last-Modified time and no opaque validator, it |  |  |
| MAY do this only if the Last-Modified time is strong in the sense |  |  |
| described here. |  |  |
| A cache or origin server receiving a conditional range request |  |  |
| ([Part5]) MUST use the strong comparison function to evaluate the |  |  |
| condition. |  |  |
| 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 |  |  |
| servers. |  |  |
| 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. |
| o MAY send a weak entity-tag instead of a strong entity-tag, if |  | o MAY send a weak entity-tag instead of a strong entity-tag, if |
| performance considerations support the use of weak entity-tags, or |  | performance considerations support the use of weak entity-tags, or |
| if it is unfeasible to send a strong entity-tag. |  | if it is unfeasible to send a strong entity-tag. |
| o SHOULD send a Last-Modified value if it is feasible to send one, |  | o SHOULD send a Last-Modified value if it is feasible to send one. |
| unless the risk of a breakdown in semantic transparency that could |  |  |
| result from using this date in an If-Modified-Since header field |  |  |
| would lead to serious problems. |  |  |
| In other words, the preferred behavior for an HTTP/1.1 origin server |  | In other words, the preferred behavior for an HTTP/1.1 origin server |
| is to send both a strong entity-tag and a Last-Modified value. |  | is to send both a strong entity-tag and a Last-Modified value. |
| In order to be legitimate, a strong entity-tag MUST change whenever |  |  |
| the associated representation changes in any way. A weak entity-tag |  |  |
| SHOULD change whenever the associated representation changes in a |  |  |
| semantically significant way. |  |  |
| Note: In order to provide semantically transparent caching, an |  |  |
| origin server must avoid reusing a specific strong entity-tag |  |  |
| value for two different representations, or reusing a specific |  |  |
| weak entity-tag value for two semantically different |  |  |
| representations. Cache entries might persist for arbitrarily long |  |  |
| periods, regardless of expiration times, so it might be |  |  |
| inappropriate to expect that a cache will never again attempt to |  |  |
| validate an entry using a validator that it obtained at some point |  |  |
| in the past. |  |  |
| HTTP/1.1 clients: |  | HTTP/1.1 clients: |
| o MUST use that entity-tag in any cache-conditional request (using |  | o MUST use that entity-tag in any cache-conditional request (using |
| If-Match or If-None-Match) if an entity-tag has been provided by |  | If-Match or If-None-Match) if an entity-tag has been provided by |
| the origin server. |  | the origin server. |
| o SHOULD use the Last-Modified value in non-subrange cache- |  | o SHOULD use the Last-Modified value in non-subrange cache- |
| conditional requests (using If-Modified-Since) if only a Last- |  | conditional requests (using If-Modified-Since) if only a Last- |
| Modified value has been provided by the origin server. |  | Modified value has been provided by the origin server. |
| skipping to change at page 13, line 38 |  | skipping to change at page 13, line 13 |
| 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. |
| 6. Header Field Definitions |  | 2.2.5. Example: Entity-tags varying on Content-Negotiated Resources |
| This section defines the syntax and semantics of HTTP/1.1 header |  | Consider a resource that is subject to content negotiation (Section 5 |
| fields related to conditional requests. |  | 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]): |
| 6.1. ETag |  | >> Request: |
| The "ETag" header field provides the current value of the entity-tag |  | GET /index HTTP/1.1 |
| (see Section 2) for one representation of the target resource. An |  | Host: www.example.com |
| entity-tag is intended for use as a resource-local identifier for |  | Accept-Encoding: gzip |
| differentiating between representations of the same resource that |  |  |
| vary over time or via content negotiation (see Section 4). |  |  |
| ETag = "ETag" ":" OWS ETag-v |  | In this case, the response might or might not use the gzip content |
| ETag-v = entity-tag |  | coding. If it does not, the response might look like: |
| Examples: |  | >> Response: |
| ETag: "xyzzy" |  | HTTP/1.1 200 OK |
| ETag: W/"xyzzy" |  | Date: Thu, 26 Mar 2010 00:05:00 GMT |
| ETag: "" |  | ETag: "123-a" |
|  |  | Content-Length: 70 |
|  |  | Vary: Accept-Encoding |
|  |  | Content-Type: text/plain |
| An entity-tag provides an "opaque" cache validator that allows for |  | Hello World! |
| more reliable validation than modification dates in situations where |  | Hello World! |
| it is inconvenient to store modification dates, where the one-second |  | Hello World! |
| resolution of HTTP date values is not sufficient, or where the origin |  | Hello World! |
| server wishes to avoid certain paradoxes that might arise from the |  | Hello World! |
| use of modification dates. |  |  |
| The principle behind entity-tags is that only the service author |  | An alternative representation that does use gzip content coding would |
| knows the semantics of a resource well enough to select an |  | be: |
| appropriate cache validation mechanism, and the specification of any |  |  |
| validator comparison function more complex than byte-equality would |  |  |
| open up a can of worms. Thus, comparisons of any other header fields |  |  |
| (except Last-Modified, for compatibility with HTTP/1.0) are never |  |  |
| used for purposes of validating a cache entry. |  |  |
| 6.2. If-Match |  | >> Response: |
| The "If-Match" header field is used to make a request method |  | HTTP/1.1 200 OK |
| conditional. A client that has one or more representations |  | Date: Thu, 26 Mar 2010 00:05:00 GMT |
| previously obtained from the resource can verify that one of those |  | ETag: "123-b" |
| representations is current by including a list of their associated |  | Content-Length: 43 |
| entity-tags in the If-Match header field. |  | Vary: Accept-Encoding |
|  |  | Content-Type: text/plain |
|  |  | Content-Encoding: gzip |
| This allows efficient updates of cached information with a minimum |  | ...binary data... |
| amount of transaction overhead. It is also used when updating |  |  |
| resources, to prevent inadvertent modification of the wrong version |  |  |
| of a resource. As a special case, the value "*" matches any current |  |  |
| representation of the resource. |  |  |
| If-Match = "If-Match" ":" OWS If-Match-v |  | Note: Content codings are a property of the representation, so |
| If-Match-v = "*" / 1#entity-tag |  | 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. |
| If any of the entity-tags match the entity-tag of the representation |  | 3. Precondition Header Fields |
| that would have been returned in the response to a similar GET |  |  |
| request (without the If-Match header field) on that resource, or if |  | This section defines the syntax and semantics of HTTP/1.1 header |
| "*" is given and any current representation exists for that resource, |  | fields for applying preconditions on requests. |
| then the server MAY perform the requested method as if the If-Match |  |  |
| header field did not exist. |  | 3.1. If-Match |
|  |  | 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 |
|  |  | one or more representations of the target resource. If-Match is |
|  |  | generally useful for resource update requests, such as PUT requests, |
|  |  | as a means for protecting against accidental overwrites when multiple |
|  |  | clients are acting in parallel on the same resource (i.e., the "lost |
|  |  | update" problem). An If-Match field-value of "*" places the |
|  |  | precondition on the existence of any current representation for the |
|  |  | target resource. |
|  |  | If-Match = "*" / 1#entity-tag |
|  |  | 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 |
|  |  | for the target resource, or if "*" is given and any current |
|  |  | representation exists for the target resource, then the server MAY |
|  |  | perform the request method as if the If-Match header field was not |
|  |  | 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, and MUST return a 412 (Precondition Failed) response. This |  | method. Instead, the server MUST respond with the 412 (Precondition |
| behavior is most useful when the client wants to prevent an updating |  | Failed) status code. |
| request method, such as PUT, from modifying a resource that has |  |  |
| changed since the client last retrieved it. |  |  |
| If the request would, without the If-Match header field, result in |  | If the request would, without the If-Match header field, result in |
| anything other than a 2xx or 412 status code, then the If-Match |  | anything other than a 2xx or 412 status code, then the If-Match |
| header field MUST be ignored. |  | header field MUST be ignored. |
| The meaning of "If-Match: *" is that the request method SHOULD be |  | Examples: |
| performed if the representation selected by the origin server (or by |  |  |
| a cache, possibly using the Vary mechanism, see Section 3.5 of |  |  |
| [Part6]) exists, and MUST NOT be performed if the representation does |  |  |
| not exist. |  |  |
| 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 |  |  |
| applied if the representation corresponding to the If-Match value (a |  |  |
| single 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 successful if the resource has been changed without their |  |  |
| knowledge. 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. |
| 6.3. If-Modified-Since |  | 3.2. If-None-Match |
| The "If-Modified-Since" header field is used to make a request method |  | The "If-None-Match" header field MAY be used to make a request method |
| conditional by date: if the representation that would have been |  | conditional on not matching any of the current entity-tag values for |
| transferred in a 200 response to a GET request has not been modified |  | representations of the target resource. If-None-Match is primarily |
| since the time specified in this field, then do not perform the |  | used in conditional GET requests to enable efficient updates of |
| method; instead, respond as detailed below. |  | cached information with a minimum amount of transaction overhead. A |
|  |  | client that has one or more representations previously obtained from |
|  |  | the target resource can send If-None-Match with a list of the |
|  |  | associated entity-tags in the hope of receiving a 304 response if at |
|  |  | least one of those representations matches the selected |
|  |  | representation. |
| If-Modified-Since = "If-Modified-Since" ":" OWS |  | If-None-Match MAY also be used with a value of "*" to prevent an |
| If-Modified-Since-v |  | unsafe request method (e.g., PUT) from inadvertently modifying an |
| If-Modified-Since-v = HTTP-date |  | existing representation of the target resource when the client |
|  |  | believes that the resource does not have a current representation. |
|  |  | This is a variation on the "lost update" problem that might arise if |
|  |  | more than one client attempts to create an initial representation for |
|  |  | the target resource. |
|  |  | If-None-Match = "*" / 1#entity-tag |
|  |  | 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 |
|  |  | representation, or if "*" is given and any current representation |
|  |  | exists for that resource, then the server MUST NOT perform the |
|  |  | requested method. Instead, if the request method was GET or HEAD, |
|  |  | the server SHOULD respond with a 304 (Not Modified) status code, |
|  |  | including the cache-related header fields (particularly ETag) of the |
|  |  | selected representation that has a matching entity-tag. For all |
|  |  | other request methods, the server MUST respond with a 412 |
|  |  | (Precondition Failed) status code. |
|  |  | 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, |
|  |  | 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 |
|  |  | return a 304 (Not Modified) response. |
|  |  | 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- |
|  |  | Match header field MUST be ignored. (See Section 2.2.4 for a |
|  |  | discussion of server behavior when both If-Modified-Since and If- |
|  |  | None-Match appear in the same request.) |
|  |  | Examples: |
|  |  | If-None-Match: "xyzzy" |
|  |  | If-None-Match: W/"xyzzy" |
|  |  | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
|  |  | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
|  |  | If-None-Match: * |
|  |  | 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 |
|  |  | undefined by this specification. |
|  |  | 3.3. If-Modified-Since |
|  |  | The "If-Modified-Since" header field MAY be used to make a request |
|  |  | method conditional by modification date: if the selected |
|  |  | representation has not been modified since the time specified in this |
|  |  | field, then do not perform the request method; instead, respond as |
|  |  | detailed below. |
|  |  | If-Modified-Since = HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| A GET method with an If-Modified-Since header field and no Range |  | A GET method with an If-Modified-Since header field and no Range |
| header field requests that the representation be transferred only if |  | header field requests that the selected representation be transferred |
| it has been modified since the date given by the If-Modified-Since |  | only if it has been modified since the date given by the If-Modified- |
| header field. The algorithm for determining this includes the |  | Since header field. The algorithm for determining this includes the |
| following cases: |  | following cases: |
| 1. If the request would normally result in anything other than a 200 |  | 1. If the request would normally result in anything other than a 200 |
| (OK) status code, or if the passed If-Modified-Since date is |  | (OK) status code, or if the passed If-Modified-Since date is |
| invalid, the response is exactly the same as for a normal GET. A |  | invalid, the response is exactly the same as for a normal GET. A |
| date which is later than the server's current time is invalid. |  | date which is later than the server's current time is invalid. |
| 2. If the representation has been modified since the If-Modified- |  | 2. If the selected representation has been modified since the If- |
| Since date, the response is exactly the same as for a normal GET. |  | Modified-Since date, the response is exactly the same as for a |
|  |  | normal GET. |
| 3. If the representation has not been modified since a valid If- |  | 3. If the selected representation has not been modified since a |
| Modified-Since date, the server SHOULD return a 304 (Not |  | valid If-Modified-Since date, the server SHOULD return a 304 (Not |
| Modified) response. |  | Modified) 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 header field modifies the meaning of If-Modified- |  | Note: The Range header field modifies the meaning of If-Modified- |
| Since; see Section 5.4 of [Part5] for full details. |  | 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. |
| skipping to change at page 17, line 7 |  | skipping to change at page 18, line 5 |
| Modified-Since date of a subsequent request, and the possibility |  | Modified-Since date of a subsequent request, and the possibility |
| of clock-skew-related problems if the If-Modified-Since date is |  | of clock-skew-related problems if the If-Modified-Since date is |
| derived from the client's clock without correction to the server's |  | derived from the client's clock without correction to the server's |
| clock. Corrections for different time bases between client and |  | clock. Corrections for different time bases between client and |
| server are at best approximate due to network latency. |  | server are at best approximate due to network latency. |
| The result of a request having both an If-Modified-Since header field |  | The result of a request having both an If-Modified-Since header field |
| and either an If-Match or an If-Unmodified-Since header fields is |  | and either an If-Match or an If-Unmodified-Since header fields is |
| undefined by this specification. |  | undefined by this specification. |
| 6.4. If-None-Match |  | 3.4. If-Unmodified-Since |
| The "If-None-Match" header field is used to make a request method |  |  |
| conditional. A client that has one or more representations |  |  |
| previously obtained from the resource can verify that none of those |  |  |
| representations is current by including a list of their associated |  |  |
| entity-tags in the If-None-Match header field. |  |  |
| This allows efficient updates of cached information with a minimum |  |  |
| amount of transaction overhead. It is also used to prevent a request |  |  |
| method (e.g., PUT) from inadvertently modifying an existing resource |  |  |
| when the client believes that the resource does not exist. |  |  |
| As a special case, the value "*" matches any current representation |  |  |
| of the resource. |  |  |
| If-None-Match = "If-None-Match" ":" OWS If-None-Match-v |  |  |
| If-None-Match-v = "*" / 1#entity-tag |  |  |
| If any of the entity-tags match the entity-tag of the representation |  |  |
| that would have been returned in the response to a similar GET |  |  |
| request (without the If-None-Match header field) on that resource, or |  |  |
| if "*" is given and any current representation exists for that |  |  |
| resource, then the server MUST NOT perform the requested method, |  |  |
| unless required to do so because the resource's modification date |  |  |
| fails to match that supplied in an If-Modified-Since header field in |  |  |
| the request. Instead, if the request method was GET or HEAD, the |  |  |
| server SHOULD respond with a 304 (Not Modified) response, including |  |  |
| the cache-related header fields (particularly ETag) of one of the |  |  |
| representations that matched. For all other request methods, the |  |  |
| server MUST respond with a 412 (Precondition Failed) status code. |  |  |
| 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, |  |  |
| 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 |  |  |
| return a 304 (Not Modified) response. |  |  |
| 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- |  |  |
| Match header field MUST be ignored. (See Section 5 for a discussion |  |  |
| of server behavior when both If-Modified-Since and If-None-Match |  |  |
| appear in the same request.) |  |  |
| The meaning of "If-None-Match: *" is that the request method MUST NOT |  |  |
| be performed if the representation selected by the origin server (or |  |  |
| by a cache, possibly using the Vary mechanism, see Section 3.5 of |  |  |
| [Part6]) exists, and SHOULD be performed if the representation does |  |  |
| not exist. This feature is intended to be useful in preventing races |  |  |
| between PUT operations. |  |  |
| Examples: |  |  |
| If-None-Match: "xyzzy" |  |  |
| If-None-Match: W/"xyzzy" |  |  |
| If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |  |  |
| If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |  |  |
| If-None-Match: * |  |  |
| 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 |  |  |
| undefined by this specification. |  |  |
| 6.5. If-Unmodified-Since |  |  |
| The "If-Unmodified-Since" header field is used to make a request |  |  |
| method conditional. If the representation that would have been |  |  |
| transferred in a 200 response to a GET request on the same resource |  |  |
| has not been modified since the time specified in this field, the |  |  |
| server SHOULD perform the requested operation as if the If- |  |  |
| Unmodified-Since header field were not present. |  |  |
| If the representation has been modified since the specified time, the |  | The "If-Unmodified-Since" header field MAY be used to make a request |
| server MUST NOT perform the requested operation, and MUST return a |  | method conditional by modification date: if the selected |
| 412 (Precondition Failed). |  | representation has been modified since the time specified in this |
|  |  | field, then the server MUST NOT perform the requested operation and |
|  |  | MUST instead respond with the 412 (Precondition Failed) status code. |
|  |  | If the selected representation has not been modified since the time |
|  |  | specified in this field, the server SHOULD perform the request method |
|  |  | as if the If-Unmodified-Since header field were not present. |
| If-Unmodified-Since = "If-Unmodified-Since" ":" OWS |  | If-Unmodified-Since = HTTP-date |
| If-Unmodified-Since-v |  |  |
| If-Unmodified-Since-v = HTTP-date |  |  |
| An example of the field is: |  | An example of the field is: |
| If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| If the request normally (i.e., without the If-Unmodified-Since header |  | If the request normally (i.e., without the If-Unmodified-Since header |
| field) would result in anything other than a 2xx or 412 status code, |  | field) would result in anything other than a 2xx or 412 status code, |
| the If-Unmodified-Since header field SHOULD be ignored. |  | the If-Unmodified-Since header field SHOULD be ignored. |
| If the specified date is invalid, the header field is ignored. |  | If the specified date is invalid, the header field MUST be ignored. |
| The result of a request having both an If-Unmodified-Since header |  | The result of a request having both an If-Unmodified-Since header |
| field and either an If-None-Match or an If-Modified-Since header |  | field and either an If-None-Match or an If-Modified-Since header |
| fields is undefined by this specification. |  | fields is undefined by this specification. |
| 6.6. Last-Modified |  | 3.5. If-Range |
| The "Last-Modified" header field indicates the date and time at which |  | The If-Range header field provides a special conditional request |
| the origin server believes the representation was last modified. |  | mechanism that is similar to If-Match and If-Unmodified-Since but |
|  |  | specific to HTTP range requests. If-Range is defined in Section 5.3 |
|  |  | of [Part5]. |
| Last-Modified = "Last-Modified" ":" OWS Last-Modified-v |  | 4. Status Code Definitions |
| Last-Modified-v = HTTP-date |  |  |
| An example of its use is |  | 4.1. 304 Not Modified |
| Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |  | The 304 status code indicates that a conditional GET request has been |
|  |  | received and would have resulted in a 200 (OK) response if it were |
|  |  | not for the fact that the condition has evaluated to false. In other |
|  |  | words, there is no need for the server to transfer a representation |
|  |  | of the target resource because the client's request indicates that it |
|  |  | already has a valid representation, as indicated by the 304 response |
|  |  | header fields, and is therefore redirecting the client to make use of |
|  |  | that stored representation as if it were the payload of a 200 |
|  |  | response. The 304 response MUST NOT contain a message-body, and thus |
|  |  | is always terminated by the first empty line after the header fields. |
| A representation is typically the sum of many parts behind the |  | A 304 response MUST include a Date header field (Section 9.3 of |
| resource interface. The last-modified time would usually be the most |  | [Part1]) unless its omission is required by Section 9.3.1 of [Part1]. |
| recent time that any of those parts were changed. How that value is |  | If a 200 response to the same request would have included any of the |
| determined for any given resource is an implementation detail beyond |  | header fields Cache-Control, Content-Location, ETag, Expires, Last- |
| the scope of this specification. What matters to HTTP is how |  | Modified, or Vary, then those same header fields MUST be sent in a |
| recipients of the Last-Modified header field can use its value to |  | 304 response. |
| make conditional requests and test the validity of locally cached |  |  |
| responses. |  |  |
| An origin server MUST NOT send a Last-Modified date which is later |  | Since the goal of a 304 response is to minimize information transfer |
| than the server's time of message origination. In such cases, where |  | when the recipient already has one or more cached representations, |
| the resource's last modification would indicate some time in the |  | the response SHOULD NOT include representation metadata other than |
| future, the server MUST replace that date with the message |  | the above listed fields unless said metadata exists for the purpose |
| origination date. |  | of guiding cache updates (e.g., future HTTP extensions). |
| An origin server SHOULD obtain the Last-Modified value of the |  | If the recipient of a 304 response does not have a cached |
| representation as close as possible to the time that it generates the |  | representation corresponding to the entity-tag indicated by the 304 |
| Date value of its response. This allows a recipient to make an |  | response, then the recipient MUST NOT use the 304 to update its own |
| accurate assessment of the representation's modification time, |  | cache. If this conditional request originated with an outbound |
| especially if the representation changes near the time that the |  | client, such as a user agent with its own cache sending a conditional |
| response is generated. |  | GET to a shared proxy, then the 304 response MAY be forwarded to the |
|  |  | outbound client. Otherwise, the recipient MUST disregard the 304 |
|  |  | response and repeat the request without any preconditions. |
| HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |  | 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 |
|  |  | the response. |
| The Last-Modified header field value is often used as a cache |  | 4.2. 412 Precondition Failed |
| validator. In simple terms, a cache entry is considered to be valid |  |  |
| if the representation has not been modified since the Last-Modified |  |  |
| value. |  |  |
| 7. IANA Considerations |  | The 412 status code indicates that one or more preconditions given in |
|  |  | the request header fields evaluated to false when tested on the |
|  |  | server. This response code allows the client to place preconditions |
|  |  | on the current resource state (its current representations and |
|  |  | metadata) and thus prevent the request method from being applied if |
|  |  | the target resource is in an unexpected state. |
| 7.1. Status Code Registration |  | 5. IANA Considerations |
|  |  | 5.1. Status Code Registration |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| <http://www.iana.org/assignments/http-status-codes> shall be updated |  | <http://www.iana.org/assignments/http-status-codes> shall be updated |
| with the registrations below: |  | with the registrations below: |
| +-------+---------------------+-------------+ |  | +-------+---------------------+-------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+---------------------+-------------+ |  | +-------+---------------------+-------------+ |
| | 304 | Not Modified | Section 3.1 | |  | | 304 | Not Modified | Section 4.1 | |
| | 412 | Precondition Failed | Section 3.2 | |  | | 412 | Precondition Failed | Section 4.2 | |
| +-------+---------------------+-------------+ |  | +-------+---------------------+-------------+ |
| 7.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 6.1 | |  | | ETag | http | standard | Section 2.2 | |
| | If-Match | http | standard | Section 6.2 | |  | | If-Match | http | standard | Section 3.1 | |
| | If-Modified-Since | http | standard | Section 6.3 | |  | | If-Modified-Since | http | standard | Section 3.3 | |
| | If-None-Match | http | standard | Section 6.4 | |  | | If-None-Match | http | standard | Section 3.2 | |
| | If-Unmodified-Since | http | standard | Section 6.5 | |  | | If-Unmodified-Since | http | standard | Section 3.4 | |
| | Last-Modified | http | standard | Section 6.6 | |  | | Last-Modified | http | standard | Section 2.1 | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 8. 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]. |
| 9. Acknowledgments |  | 7. Acknowledgments |
| 10. References |  | 8. References |
| 10.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-13 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-14 |
| (work in progress), March 2011. |  | (work in progress), April 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-13 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-14 |
| (work in progress), March 2011. |  | (work in progress), April 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-13 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-14 (work |
| in progress), March 2011. |  | in progress), April 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-13 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-14 (work in |
| progress), March 2011. |  | progress), April 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. |
| 10.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., |
| 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. |
|  |  | [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed |
|  |  | 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 4 and 6.4). |  | (Sections 2.2.2 and 3.2). |
|  |  | Change ABNF productions for header fields to only define the field |
|  |  | value. (Section 3) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| ETag = "ETag:" OWS ETag-v |  | ETag = entity-tag |
| ETag-v = entity-tag |  |  |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| If-Match = "If-Match:" OWS If-Match-v |  | If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
| If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |  |  |
| entity-tag ] ) ) |  | entity-tag ] ) ) |
| If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v |  | If-Modified-Since = HTTP-date |
| If-Modified-Since-v = HTTP-date |  | If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |
| If-None-Match = "If-None-Match:" OWS If-None-Match-v |  |  |
| If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS |  |  |
| entity-tag ] ) ) |  | entity-tag ] ) ) |
| If-Unmodified-Since = "If-Unmodified-Since:" OWS |  | If-Unmodified-Since = HTTP-date |
| If-Unmodified-Since-v |  |  |
| If-Unmodified-Since-v = HTTP-date |  |  |
| Last-Modified = "Last-Modified:" OWS Last-Modified-v |  | Last-Modified = HTTP-date |
| Last-Modified-v = 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 1.2.2> |
| weak = %x57.2F ; W/ |  | weak = %x57.2F ; W/ |
| skipping to change at page 25, line 29 |  | skipping to change at page 25, line 16 |
| None. |  | None. |
| C.14. Since draft-ietf-httpbis-p4-conditional-12 |  | C.14. Since draft-ietf-httpbis-p4-conditional-12 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |
| Classification" |  | Classification" |
|  |  | C.15. Since draft-ietf-httpbis-p4-conditional-13 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/89>: "If-* and |
|  |  | entities" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/101>: "Definition of |
|  |  | validator weakness" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
|  |  | ABNFs for header fields" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/269>: "ETags and |
|  |  | Quotes" |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 8 |  | 304 Not Modified (status code) 18 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 8 |  | 412 Precondition Failed (status code) 19 |
| E |  | E |
| ETag header field 13 |  | ETag header field 8 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 6 |  | entity-tag 8 |
| ETag 13 |  | ETag 8 |
| ETag-v 13 |  |  |
| If-Match 14 |  | If-Match 14 |
| If-Match-v 14 |  | If-Modified-Since 16 |
| If-Modified-Since 15 |  | If-None-Match 15 |
| If-Modified-Since-v 15 |  |  |
| If-None-Match 17 |  |  |
| If-None-Match-v 17 |  |  |
| If-Unmodified-Since 18 |  | If-Unmodified-Since 18 |
| If-Unmodified-Since-v 18 |  | Last-Modified 6 |
| Last-Modified 19 |  | opaque-tag 8 |
| Last-Modified-v 19 |  | weak 8 |
| opaque-tag 6 |  |  |
| weak 6 |  |  |
| H |  | H |
| Header Fields |  | Header Fields |
| ETag 13 |  | ETag 8 |
| If-Match 14 |  | If-Match 14 |
| If-Modified-Since 15 |  | If-Modified-Since 16 |
| If-None-Match 17 |  | If-None-Match 15 |
| If-Unmodified-Since 18 |  | If-Unmodified-Since 18 |
| Last-Modified 19 |  | Last-Modified 6 |
| I |  | I |
| If-Match header field 14 |  | If-Match header field 14 |
| If-Modified-Since header field 15 |  | If-Modified-Since header field 16 |
| If-None-Match header field 17 |  | If-None-Match header field 15 |
| If-Unmodified-Since header field 18 |  | If-Unmodified-Since header field 18 |
| L |  | L |
| Last-Modified header field 19 |  | Last-Modified header field 6 |
|  |  | M |
|  |  | metadata 6 |
| S |  | S |
|  |  | selected representation 5 |
| Status Codes |  | Status Codes |
| 304 Not Modified 8 |  | 304 Not Modified 18 |
| 412 Precondition Failed 8 |  | 412 Precondition Failed 19 |
|  |  | V |
|  |  | validator 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. 132 change blocks.
| 520 lines changed or deleted |  | 531 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/