| draft-ietf-httpbis-p4-conditional-10.txt |  | draft-ietf-httpbis-p4-conditional-11.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: January 13, 2011 J. Mogul |  | Expires: February 5, 2011 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 12, 2010 |  | August 4, 2010 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-10 |  | draft-ietf-httpbis-p4-conditional-11 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 4 of the |  | information initiative since 1990. This document is Part 4 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |
| request header fields for indicating conditional requests and the |  | request header fields for indicating conditional requests and the |
| rules for constructing responses to those requests. |  | rules for constructing responses to those requests. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.11. |  | The changes in this draft are summarized in Appendix C.12. |
| 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 13, 2011. |  | This Internet-Draft will expire on February 5, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 13 |  | skipping to change at page 3, line 13 |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2.2. ABNF Rules defined in other Parts of the |  | 1.2.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 5 |  | Specification . . . . . . . . . . . . . . . . . . . . 5 |
| 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2.1. Example: Entity Tags varying on Content-Negotiated |  | 2.1. Example: Entity-tags varying on Content-Negotiated |
| Resources . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | Resources . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 |
| 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7 |  | 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7 |
| 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8 |  | 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 7 |
| 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8 |  | 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8 |
| 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 11 |  | 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 10 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12 |
| 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14 |  | 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14 |
| 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16 |  | 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16 |
| 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |  | 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 |
| 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18 |  | 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 |
| 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |  | 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 |
| 7.2. Message Header Registration . . . . . . . . . . . . . . . 19 |  | 7.2. Header Field Registration . . . . . . . . . . . . . . . . 19 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 20 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |
| A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 |  |  |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 21 |  | publication) . . . . . . . . . . . . . . . . . . . . 21 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22 |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22 |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22 |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23 |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23 |  | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23 |
| C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23 |  | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23 |
| C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23 |  | C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23 |
| C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23 |  | C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23 |
|  |  | C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 response metadata for indicating |  | This document defines HTTP/1.1 response metadata for indicating |
| potential changes to payload content, including modification time |  | potential changes to payload content, including modification time |
| stamps and opaque entity-tags, and the HTTP conditional request |  | stamps and opaque entity-tags, and the HTTP conditional request |
| mechanisms that allow preconditions to be placed on a request method. |  | mechanisms that allow preconditions to be placed on a request method. |
| Conditional GET requests allow for efficient cache updates. Other |  | Conditional GET requests allow for efficient cache updates. Other |
| conditional request methods are used to protect against overwriting |  | conditional request methods are used to protect against overwriting |
| skipping to change at page 5, line 21 |  | skipping to change at page 5, line 21 |
| 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> |
| 1.2.2. ABNF Rules defined in other Parts of the Specification |  | 1.2.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| 2. Entity Tags |  | 2. Entity-Tags |
| Entity tags are used for comparing two or more entities from the same |  | Entity-tags are used for comparing two or more representations of the |
| requested resource. HTTP/1.1 uses entity tags in the ETag |  | same resource. HTTP/1.1 uses entity-tags in the ETag (Section 6.1), |
| (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4), |  | If-Match (Section 6.2), If-None-Match (Section 6.4), and If-Range |
| and If-Range (Section 5.3 of [Part5]) header fields. The definition |  | (Section 5.3 of [Part5]) header fields. The definition of how they |
| of how they are used and compared as cache validators is in |  | are used and compared as cache validators is in Section 4. An |
| Section 4. An entity tag consists of an opaque quoted string, |  | entity-tag consists of an opaque quoted string, possibly prefixed by |
| possibly prefixed by a weakness indicator. |  | a weakness indicator. |
| entity-tag = [ weak ] opaque-tag |  | entity-tag = [ weak ] opaque-tag |
| weak = %x57.2F ; "W/", case-sensitive |  | weak = %x57.2F ; "W/", case-sensitive |
| opaque-tag = quoted-string |  | opaque-tag = quoted-string |
| A "strong entity tag" MAY be shared by two entities of a resource |  | A "strong entity-tag" MAY be shared by two representations of a |
| only if they are equivalent by octet equality. |  | resource only if they are equivalent by octet equality. |
| A "weak entity tag," indicated by the "W/" prefix, MAY be shared by |  | A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by |
| two entities of a resource only if the entities are equivalent and |  | two representations of a resource only if the representations are |
| could be substituted for each other with no significant change in |  | equivalent and could be substituted for each other with no |
| semantics. A weak entity tag can only be used for weak comparison. |  | 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 entities |  | An entity-tag MUST be unique across all versions of all |
| associated with a particular resource. A given entity tag value MAY |  | representations associated with a particular resource. A given |
| be used for entities obtained by requests on different URIs. The use |  | entity-tag value MAY be used for representations obtained by requests |
| of the same entity tag value in conjunction with entities obtained by |  | on different URIs. The use of the same entity-tag value in |
| requests on different URIs does not imply the equivalence of those |  | conjunction with representations obtained by requests on different |
| entities. |  | URIs does not imply the equivalence of those representations. |
| 2.1. Example: Entity Tags varying on Content-Negotiated Resources |  | 2.1. Example: Entity-tags varying on Content-Negotiated Resources |
| Consider a resource that is subject to content negotiation (Section 4 |  | Consider a resource that is subject to content negotiation (Section 5 |
| of [Part3]), and where the representations returned upon a GET |  | of [Part3]), and where the representations returned upon a GET |
| request vary based on the Accept-Encoding request header field |  | request vary based on the Accept-Encoding request header field |
| (Section 5.3 of [Part3]): |  | (Section 6.3 of [Part3]): |
| >> Request: |  | >> Request: |
| GET /index HTTP/1.1 |  | GET /index HTTP/1.1 |
| Host: www.example.com |  | Host: www.example.com |
| Accept-Encoding: gzip |  | Accept-Encoding: gzip |
| In this case, the response may use the gzip Content Coding or not. |  | In this case, the response might or might not use the gzip content |
| If it does, it might look like that: |  | coding. If it does not, the response might look like: |
| >> Response: |  | >> Response: |
| HTTP/1.1 200 OK |  | HTTP/1.1 200 OK |
| Date: Thu, 26 Mar 2010 00:05:00 GMT |  | Date: Thu, 26 Mar 2010 00:05:00 GMT |
| ETag: "123-a" |  | ETag: "123-a" |
| Content-Length: 70 |  | Content-Length: 70 |
| Vary: Accept-Encoding |  | Vary: Accept-Encoding |
| Content-Type: text/plain |  | Content-Type: text/plain |
| Hello World! |  | Hello World! |
| Hello World! |  | Hello World! |
| Hello World! |  | Hello World! |
| Hello World! |  | Hello World! |
| Hello World! |  | Hello World! |
| A variant that does use gzip Content Coding would be: |  | An alternative representation that does use gzip content coding would |
|  |  | be: |
| >> Response: |  | >> Response: |
| HTTP/1.1 200 OK |  | HTTP/1.1 200 OK |
| Date: Thu, 26 Mar 2010 00:05:00 GMT |  | Date: Thu, 26 Mar 2010 00:05:00 GMT |
| ETag: "123-b" |  | ETag: "123-b" |
| Content-Length: 43 |  | Content-Length: 43 |
| Vary: Accept-Encoding |  | Vary: Accept-Encoding |
| Content-Type: text/plain |  | Content-Type: text/plain |
| Content-Encoding: gzip |  | Content-Encoding: gzip |
| ...binary data... |  | ...binary data... |
| Note: Content Codings are a property of the response entity, thus |  | Note: Content codings are a property of the representation, so |
| affect the Entity Tag. An alternative are Transfer Codings |  | therefore an entity-tag of an encoded representation must be |
| (Section 6.2 of [Part1]) which apply only to the transfer of the |  | distinct from an unencoded representation to prevent conflicts |
| message, and thus do not require assigning distinct entity tags. |  | 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 |  | 3. Status Code Definitions |
| 3.1. 304 Not Modified |  | 3.1. 304 Not Modified |
| If the client has performed a conditional GET request and access is |  | If the client has performed a conditional GET request and access is |
| allowed, but the document has not been modified, the server SHOULD |  | allowed, but the document has not been modified, the server SHOULD |
| respond with this status code. The 304 response MUST NOT contain a |  | respond with this status code. The 304 response MUST NOT contain a |
| message-body, and thus is always terminated by the first empty line |  | message-body, and thus is always terminated by the first empty line |
| after the header fields. |  | after the header fields. |
| The response MUST include the following header fields: |  | A 304 response MUST include a Date header field (Section 9.3 of |
|  |  | [Part1]) unless its omission is required by Section 9.3.1 of [Part1]. |
| o Date, 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- |
| If a clockless origin server obeys these rules, and proxies and |  | Modified, or Vary, then those same header fields MUST be sent in a |
| clients add their own Date to any response received without one |  | 304 response. |
| (as already specified by Section 9.3 of [Part1], caches will |  |  |
| operate correctly. |  |  |
| o ETag and/or Content-Location, if the header would have been sent |  |  |
| in a 200 response to the same request. |  |  |
| o Expires, Cache-Control, and/or Vary, if the field-value might |  |  |
| differ from that sent in any previous response for the same |  |  |
| variant. |  |  |
| If the conditional GET used a strong cache validator (see Section 4), |  | Since the goal of a 304 response is to minimize information transfer |
| the response SHOULD NOT include other entity-headers. Otherwise |  | when the recipient already has one or more cached representations, |
| (i.e., the conditional GET used a weak validator), the response MUST |  | the response SHOULD NOT include representation metadata other than |
| NOT include other entity-headers; this prevents inconsistencies |  | the above listed fields unless said metadata exists for the purpose |
| between cached entity-bodies and updated headers. |  | of guiding cache updates (e.g., future HTTP extensions). |
| If a 304 response indicates an entity not currently cached, then the |  | If a 304 response includes an entity-tag that indicates a |
| cache MUST disregard the response and repeat the request without the |  | 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. |  | conditional. |
| If a cache uses a received 304 response to update a cache entry, the |  | If a cache uses a received 304 response to update a cache entry, the |
| cache MUST update the entry to reflect any new field values given in |  | cache MUST update the entry to reflect any new field values given in |
| the response. |  | the response. |
| 3.2. 412 Precondition Failed |  | 3.2. 412 Precondition Failed |
| The precondition given in one or more of the request-header fields |  | The precondition given in one or more of the request-header fields |
| evaluated to false when it was tested on the server. This response |  | evaluated to false when it was tested on the server. This response |
| code allows the client to place preconditions on the current resource |  | code allows the client to place preconditions on the current resource |
| metainformation (header field data) and thus prevent the requested |  | metadata (header field data) and thus prevent the requested method |
| method from being applied to a resource other than the one intended. |  | from being applied to a resource other than the one intended. |
| 4. Weak and Strong Validators |  | 4. Weak and Strong Validators |
| Since both origin servers and caches will compare two validators to |  | Since both origin servers and caches will compare two validators to |
| decide if they represent the same or different entities, one normally |  | decide if they represent the same or different representations, one |
| would expect that if the entity (the entity-body or any entity- |  | normally would expect that if the representation (including both |
| headers) changes in any way, then the associated validator would |  | representation header fields and representation body) changes in any |
| change as well. If this is true, then we call this validator a |  | way, then the associated validator would change as well. If this is |
| "strong validator." |  | true, then we call this validator a "strong validator". |
| However, there might be cases when a server prefers to change the |  | However, there might be cases when a server prefers to change the |
| validator only on semantically significant changes, and not when |  | validator only on semantically significant changes, and not when |
| insignificant aspects of the entity change. A validator that does |  | insignificant aspects of the representation change. A validator that |
| not always change when the resource changes is a "weak validator." |  | does not always change when the representation changes is a "weak |
|  |  | validator". |
| Entity tags are normally "strong validators," but the protocol |  | An entity-tag is normally a strong validator, but the protocol |
| provides a mechanism to tag an entity tag as "weak." One can think |  | provides a mechanism to tag an entity-tag as "weak". One can think |
| of a strong validator as one that changes whenever the bits of an |  | of a strong validator as one that changes whenever the sequence of |
| entity changes, while a weak value changes whenever the meaning of an |  | bits in a representation changes, while a weak value changes whenever |
| entity changes. Alternatively, one can think of a strong validator |  | the meaning of a representation changes. Alternatively, one can |
| as part of an identifier for a specific entity, while a weak |  | think of a strong validator as part of an identifier for a specific |
| validator is part of an identifier for a set of semantically |  | representation, whereas a weak validator is part of an identifier for |
| equivalent entities. |  | a set of semantically equivalent representations. |
| Note: One example of a strong validator is an integer that is |  | Note: One example of a strong validator is an integer that is |
| incremented in stable storage every time an entity is changed. |  | incremented in stable storage every time a representation is |
|  |  | changed. |
| An entity's modification time, if represented with one-second |  | A representation's modification time, if defined with only one- |
| resolution, could be a weak validator, since it is possible that |  | second resolution, could be a weak validator, since it is possible |
| the resource might be modified twice during a single second. |  | that the representation might be modified twice during a single |
|  |  | 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 "use" of a validator is either when a client generates a request |
| and includes the validator in a validating header field, or when a |  | and includes the validator in a validating header field, or when a |
| server compares two validators. |  | server compares two validators. |
| Strong validators are usable in any context. Weak validators are |  | Strong validators are usable in any context. Weak validators are |
| only usable in contexts that do not depend on exact equality of an |  | only usable in contexts that do not depend on exact equality of a |
| entity. For example, either kind is usable for a conditional GET of |  | representation. For example, either kind is usable for a normal |
| a full entity. However, only a strong validator is usable for a sub- |  | conditional GET. However, only a strong validator is usable for a |
| range retrieval, since otherwise the client might end up with an |  | sub-range retrieval, since otherwise the client might end up with an |
| internally inconsistent entity. |  | internally inconsistent representation. |
| Clients MUST NOT use weak validators in range requests ([Part5]). |  | Clients MUST NOT use weak validators in range requests ([Part5]). |
| The only function that HTTP/1.1 defines on validators is comparison. |  | The only function that HTTP/1.1 defines on validators is comparison. |
| There are two validator comparison functions, depending on whether |  | There are two validator 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. |
| 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. |  | Section 2 gives the syntax for entity-tags. |
| A Last-Modified time, when used as a validator in a request, is |  | A Last-Modified time, when used as a validator in a request, is |
| implicitly weak unless it is possible to deduce that it is strong, |  | implicitly weak unless it is possible to deduce that it is strong, |
| using the following rules: |  | using the following rules: |
| o The validator is being compared by an origin server to the actual |  | o The validator is being compared by an origin server to the actual |
| current validator for the entity and, |  | current validator for the representation and, |
| o That origin server reliably knows that the associated entity did |  | o That origin server reliably knows that the associated |
| not change twice during the second covered by the presented |  | representation did not change twice during the second covered by |
| validator. |  | the presented validator. |
| or |  | or |
| o The validator is about to be used by a client in an If-Modified- |  | o The validator is about to be used by a client in an If-Modified- |
| Since or If-Unmodified-Since header, because the client has a |  | Since or If-Unmodified-Since header, because the client has a |
| cache entry for the associated entity, and |  | cache entry for the associated representation, and |
| o That cache entry includes a Date value, which gives the time when |  | o That cache entry includes a Date value, which gives the time when |
| the origin server sent the original response, and |  | the origin server sent the original response, and |
| o The presented Last-Modified time is at least 60 seconds before the |  | o The presented Last-Modified time is at least 60 seconds before the |
| Date value. |  | Date value. |
| or |  | or |
| o The validator is being compared by an intermediate cache to the |  | o The validator is being compared by an intermediate cache to the |
| validator stored in its cache entry for the entity, and |  | validator stored in its cache entry for the 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. |
| 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 |
| skipping to change at page 11, line 5 |  | skipping to change at page 10, line 48 |
| described here. |  | described here. |
| A cache or origin server receiving a conditional range request |  | A cache or origin server receiving a conditional range request |
| ([Part5]) MUST use the strong comparison function to evaluate the |  | ([Part5]) MUST use the strong comparison function to evaluate the |
| condition. |  | condition. |
| These rules allow HTTP/1.1 caches and clients to safely perform sub- |  | These rules allow HTTP/1.1 caches and clients to safely perform sub- |
| range retrievals on values that have been obtained from HTTP/1.0 |  | range retrievals on values that have been obtained from HTTP/1.0 |
| servers. |  | servers. |
| 5. Rules for When to Use Entity Tags and Last-Modified Dates |  | 5. Rules for When to Use Entity-tags and Last-Modified Dates |
| We adopt a set of rules and recommendations for origin servers, |  | We adopt a set of rules and recommendations for origin servers, |
| clients, and caches regarding when various validator types ought to |  | clients, and caches regarding when various validator types ought to |
| be used, and for what purposes. |  | be used, and for what purposes. |
| HTTP/1.1 origin servers: |  | HTTP/1.1 origin servers: |
| o SHOULD send an entity tag validator unless it is not feasible to |  | o SHOULD send an entity-tag validator unless it is not feasible to |
| generate one. |  | generate one. |
| o MAY send a weak entity tag instead of a strong entity tag, if |  | o MAY send a weak entity-tag instead of a strong entity-tag, if |
| performance considerations support the use of weak entity tags, or |  | performance considerations support the use of weak entity-tags, or |
| if it is unfeasible to send a strong entity tag. |  | if it is unfeasible to send a strong entity-tag. |
| o SHOULD send a Last-Modified value if it is feasible to send one, |  | o SHOULD send a Last-Modified value if it is feasible to send one, |
| unless the risk of a breakdown in semantic transparency that could |  | unless the risk of a breakdown in semantic transparency that could |
| result from using this date in an If-Modified-Since header would |  | result from using this date in an If-Modified-Since header would |
| lead to serious problems. |  | lead to serious problems. |
| In other words, the preferred behavior for an HTTP/1.1 origin server |  | In other words, the preferred behavior for an HTTP/1.1 origin server |
| is to send both a strong entity tag and a Last-Modified value. |  | is to send both a strong entity-tag and a Last-Modified value. |
| In order to be legal, a strong entity tag MUST change whenever the |  | In order to be legal, a strong entity-tag MUST change whenever the |
| associated entity changes in any way. A weak entity tag SHOULD |  | associated representation changes in any way. A weak entity-tag |
| change whenever the associated entity changes in a semantically |  | SHOULD change whenever the associated representation changes in a |
| significant way. |  | semantically significant way. |
| Note: In order to provide semantically transparent caching, an |  | Note: In order to provide semantically transparent caching, an |
| origin server must avoid reusing a specific strong entity tag |  | origin server must avoid reusing a specific strong entity-tag |
| value for two different entities, or reusing a specific weak |  | value for two different representations, or reusing a specific |
| entity tag value for two semantically different entities. Cache |  | weak entity-tag value for two semantically different |
| entries might persist for arbitrarily long periods, regardless of |  | representations. Cache entries might persist for arbitrarily long |
| expiration times, so it might be inappropriate to expect that a |  | periods, regardless of expiration times, so it might be |
| cache will never again attempt to validate an entry using a |  | inappropriate to expect that a cache will never again attempt to |
| validator that it obtained at some point in the past. |  | 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. |
| o MAY use the Last-Modified value in subrange cache-conditional |  | o MAY use the Last-Modified value in subrange cache-conditional |
| requests (using If-Unmodified-Since) if only a Last-Modified value |  | requests (using If-Unmodified-Since) if only a Last-Modified value |
| has been provided by an HTTP/1.0 origin server. The user agent |  | has been provided by an HTTP/1.0 origin server. The user agent |
| SHOULD provide a way to disable this, in case of difficulty. |  | SHOULD provide a way to disable this, in case of difficulty. |
| o SHOULD use both validators in cache-conditional requests if both |  | o SHOULD use both validators in cache-conditional requests if both |
| an entity tag and a Last-Modified value have been provided by the |  | an entity-tag and a Last-Modified value have been provided by the |
| origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to |  | origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to |
| respond appropriately. |  | respond appropriately. |
| An HTTP/1.1 origin server, upon receiving a conditional request that |  | An HTTP/1.1 origin server, upon receiving a conditional request that |
| includes both a Last-Modified date (e.g., in an If-Modified-Since or |  | includes both a Last-Modified date (e.g., in an If-Modified-Since or |
| If-Unmodified-Since header field) and one or more entity tags (e.g., |  | If-Unmodified-Since header field) and one or more entity-tags (e.g., |
| in an If-Match, If-None-Match, or If-Range header field) as cache |  | in an If-Match, If-None-Match, or If-Range header field) as cache |
| validators, MUST NOT return a response status of 304 (Not Modified) |  | validators, MUST NOT return a response status code of 304 (Not |
| unless doing so is consistent with all of the conditional header |  | Modified) unless doing so is consistent with all of the conditional |
| fields in the request. |  | header fields in the request. |
| An HTTP/1.1 caching proxy, upon receiving a conditional request that |  | An HTTP/1.1 caching proxy, upon receiving a conditional request that |
| includes both a Last-Modified date and one or more entity tags as |  | includes both a Last-Modified date and one or more entity-tags as |
| cache validators, MUST NOT return a locally cached response to the |  | cache validators, MUST NOT return a locally cached response to the |
| client unless that cached response is consistent with all of the |  | client unless that cached response is consistent with all of the |
| conditional header fields in the request. |  | conditional header fields in the request. |
| Note: The general principle behind these rules is that HTTP/1.1 |  | Note: The general principle behind these rules is that HTTP/1.1 |
| servers and clients should transmit as much non-redundant |  | servers and clients ought to transmit as much non-redundant |
| information as is available in their responses and requests. |  | information as is available in their responses and requests. |
| HTTP/1.1 systems receiving this information will make the most |  | HTTP/1.1 systems receiving this information will make the most |
| conservative assumptions about the validators they receive. |  | conservative assumptions about the validators they receive. |
| HTTP/1.0 clients and caches will ignore entity tags. Generally, |  | HTTP/1.0 clients and caches will ignore entity-tags. Generally, |
| last-modified values received or used by these systems will |  | last-modified values received or used by these systems will |
| support transparent and efficient caching, and so HTTP/1.1 origin |  | support transparent and efficient caching, and so HTTP/1.1 origin |
| servers should provide Last-Modified values. In those rare cases |  | servers should provide Last-Modified values. In those rare cases |
| where the use of a Last-Modified value as a validator by an |  | where the use of a Last-Modified value as a validator by an |
| HTTP/1.0 system could result in a serious problem, then HTTP/1.1 |  | HTTP/1.0 system could result in a serious problem, then HTTP/1.1 |
| origin servers should not provide one. |  | origin servers should not provide one. |
| 6. Header Field Definitions |  | 6. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to conditional requests. |  | fields related to conditional requests. |
| For entity-header fields, both sender and recipient refer to either |  |  |
| the client or the server, depending on who sends and who receives the |  |  |
| entity. |  |  |
| 6.1. ETag |  | 6.1. ETag |
| The "ETag" response-header field provides the current value of the |  | The "ETag" response-header field provides the current value of the |
| entity tag (see Section 2) for the requested variant, which may be |  | entity-tag (see Section 2) for one representation of the target |
| used for comparison with other entities from the same resource (see |  | resource. An entity-tag is intended for use as a resource-local |
|  |  | identifier for differentiating between representations of the same |
|  |  | resource that vary over time or via content negotiation (see |
| Section 4). |  | Section 4). |
| ETag = "ETag" ":" OWS ETag-v |  | ETag = "ETag" ":" OWS ETag-v |
| ETag-v = entity-tag |  | ETag-v = entity-tag |
| Examples: |  | Examples: |
| ETag: "xyzzy" |  | ETag: "xyzzy" |
| ETag: W/"xyzzy" |  | ETag: W/"xyzzy" |
| ETag: "" |  | ETag: "" |
| The ETag response-header field value, an entity tag, provides for an |  | An entity-tag provides an "opaque" cache validator that allows for |
| "opaque" cache validator. This might allow more reliable validation |  | more reliable validation than modification dates in situations where |
| in situations where it is inconvenient to store modification dates, |  | it is inconvenient to store modification dates, where the one-second |
| where the one-second resolution of HTTP date values is not |  | resolution of HTTP date values is not sufficient, or where the origin |
| sufficient, or where the origin server wishes to avoid certain |  | server wishes to avoid certain paradoxes that might arise from the |
| paradoxes that might arise from the use of modification dates. |  | use of modification dates. |
| The principle behind entity tags is that only the service author |  | The principle behind entity-tags is that only the service author |
| knows the semantics of a resource well enough to select an |  | knows the semantics of a resource well enough to select an |
| appropriate cache validation mechanism, and the specification of any |  | appropriate cache validation mechanism, and the specification of any |
| validator comparison function more complex than byte-equality would |  | validator comparison function more complex than byte-equality would |
| open up a can of worms. Thus, comparisons of any other headers |  | open up a can of worms. Thus, comparisons of any other headers |
| (except Last-Modified, for compatibility with HTTP/1.0) are never |  | (except Last-Modified, for compatibility with HTTP/1.0) are never |
| used for purposes of validating a cache entry. |  | used for purposes of validating a cache entry. |
| 6.2. If-Match |  | 6.2. If-Match |
| The "If-Match" request-header field is used to make a request method |  | The "If-Match" request-header field is used to make a request method |
| conditional. A client that has one or more entities previously |  | conditional. A client that has one or more representations |
| obtained from the resource can verify that one of those entities is |  | previously obtained from the resource can verify that one of those |
| current by including a list of their associated entity tags in the |  | representations is current by including a list of their associated |
| If-Match header field. |  | entity-tags in the If-Match header field. |
| This allows efficient updates of cached information with a minimum |  | This allows efficient updates of cached information with a minimum |
| amount of transaction overhead. It is also used when updating |  | amount of transaction overhead. It is also used when updating |
| resources, to prevent inadvertent modification of the wrong version |  | resources, to prevent inadvertent modification of the wrong version |
| of a resource. As a special case, the value "*" matches any current |  | of a resource. As a special case, the value "*" matches any current |
| entity of the resource. |  | representation of the resource. |
| If-Match = "If-Match" ":" OWS If-Match-v |  | If-Match = "If-Match" ":" OWS If-Match-v |
| If-Match-v = "*" / 1#entity-tag |  | If-Match-v = "*" / 1#entity-tag |
| If any of the entity tags match the entity tag of the entity that |  | If any of the entity-tags match the entity-tag of the representation |
| would have been returned in the response to a similar GET request |  | that would have been returned in the response to a similar GET |
| (without the If-Match header) on that resource, or if "*" is given |  | request (without the If-Match header) on that resource, or if "*" is |
| and any current entity exists for that resource, then the server MAY |  | given and any current representation exists for that resource, then |
| perform the requested method as if the If-Match header field did not |  | the server MAY perform the requested method as if the If-Match header |
| exist. |  | field did not exist. |
| If none of the entity tags match, or if "*" is given and no current |  | If none of the entity-tags match, or if "*" is given and no current |
| entity exists, the server MUST NOT perform the requested method, and |  | representation exists, the server MUST NOT perform the requested |
| MUST return a 412 (Precondition Failed) response. This behavior is |  | method, and MUST return a 412 (Precondition Failed) response. This |
| most useful when the client wants to prevent an updating method, such |  | behavior is most useful when the client wants to prevent an updating |
| as PUT, from modifying a resource that has changed since the client |  | method, such as PUT, from modifying a resource that has changed since |
| last retrieved it. |  | the client last retrieved it. |
| If the request would, without the If-Match header field, result in |  | If the request would, without the If-Match header field, result in |
| anything other than a 2xx or 412 status, then the If-Match header |  | anything other than a 2xx or 412 status code, then the If-Match |
| MUST be ignored. |  | header MUST be ignored. |
| The meaning of "If-Match: *" is that the method SHOULD be performed |  | The meaning of "If-Match: *" is that the method SHOULD be performed |
| if the representation selected by the origin server (or by a cache, |  | if the representation selected by the origin server (or by a cache, |
| possibly using the Vary mechanism, see Section 3.5 of [Part6]) |  | possibly using the Vary mechanism, see Section 3.5 of [Part6]) |
| exists, and MUST NOT be performed if the representation does not |  | exists, and MUST NOT be performed if the representation does not |
| exist. |  | exist. |
| A request intended to update a resource (e.g., a PUT) MAY include an |  | A request intended to update a resource (e.g., a PUT) MAY include an |
| If-Match header field to signal that the request method MUST NOT be |  | If-Match header field to signal that the request method MUST NOT be |
| applied if the entity corresponding to the If-Match value (a single |  | applied if the representation corresponding to the If-Match value (a |
| entity tag) is no longer a representation of that resource. This |  | single entity-tag) is no longer a representation of that resource. |
| allows the user to indicate that they do not wish the request to be |  | This allows the user to indicate that they do not wish the request to |
| successful if the resource has been changed without their knowledge. |  | be successful if the resource has been changed without their |
| Examples: |  | 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 |  | 6.3. If-Modified-Since |
| The "If-Modified-Since" request-header field is used to make a |  | The "If-Modified-Since" request-header field is used to make a |
| request method conditional: if the requested variant has not been |  | request method conditional by date: if the representation that would |
| modified since the time specified in this field, the server will not |  | have been transferred in a 200 response to a GET request has not been |
| return an entity; instead, a 304 (Not Modified) response will be |  | modified since the time specified in this field, then do not perform |
| returned. |  | the method; instead, respond as detailed below. |
| If-Modified-Since = "If-Modified-Since" ":" OWS |  | If-Modified-Since = "If-Modified-Since" ":" OWS |
| If-Modified-Since-v |  | If-Modified-Since-v |
| If-Modified-Since-v = HTTP-date |  | If-Modified-Since-v = HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| A GET method with an If-Modified-Since header and no Range header |  | A GET method with an If-Modified-Since header and no Range header |
| requests that the identified entity be transferred only if it has |  | requests that the representation be transferred only if it has been |
| been modified since the date given by the If-Modified-Since header. |  | modified since the date given by the If-Modified-Since header. The |
| The algorithm for determining this includes the following cases: |  | algorithm for determining this includes the following cases: |
| 1. If the request would normally result in anything other than a 200 |  | 1. If the request would normally result in anything other than a 200 |
| (OK) status, or if the passed If-Modified-Since date is invalid, |  | (OK) status code, or if the passed If-Modified-Since date is |
| the response is exactly the same as for a normal GET. A date |  | invalid, the response is exactly the same as for a normal GET. A |
| 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 variant has been modified since the If-Modified-Since |  | 2. If the representation has been modified since the If-Modified- |
| date, the response is exactly the same as for a normal GET. |  | Since date, the response is exactly the same as for a normal GET. |
| 3. If the variant has not been modified since a valid If-Modified- |  | 3. If the representation has not been modified since a valid If- |
| Since date, the server SHOULD return a 304 (Not Modified) |  | Modified-Since date, the server SHOULD return a 304 (Not |
| 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 request-header field modifies the meaning of If- |  | Note: The Range request-header field modifies the meaning of If- |
| Modified-Since; see Section 5.4 of [Part5] for full details. |  | Modified-Since; see Section 5.4 of [Part5] for full details. |
| Note: If-Modified-Since times are interpreted by the server, whose |  | Note: If-Modified-Since times are interpreted by the server, whose |
| clock might not be synchronized with the client. |  | clock might not be synchronized with the client. |
| Note: When handling an If-Modified-Since header field, some |  | Note: When handling an If-Modified-Since header field, some |
| servers will use an exact date comparison function, rather than a |  | servers will use an exact date comparison function, rather than a |
| less-than function, for deciding whether to send a 304 (Not |  | less-than function, for deciding whether to send a 304 (Not |
| Modified) response. To get best results when sending an If- |  | Modified) response. To get best results when sending an If- |
| Modified-Since header field for cache validation, clients are |  | Modified-Since header field for cache validation, clients are |
| advised to use the exact date string received in a previous Last- |  | advised to use the exact date string received in a previous Last- |
| Modified header field whenever possible. |  | Modified header field whenever possible. |
| Note: If a client uses an arbitrary date in the If-Modified-Since |  | Note: If a client uses an arbitrary date in the If-Modified-Since |
| header instead of a date taken from the Last-Modified header for |  | header instead of a date taken from the Last-Modified header for |
| the same request, the client should be aware of the fact that this |  | the same request, the client needs to be aware that this date is |
| date is interpreted in the server's understanding of time. The |  | interpreted in the server's understanding of time. Unsynchronized |
| client should consider unsynchronized clocks and rounding problems |  | clocks and rounding problems, due to the different encodings of |
| due to the different encodings of time between the client and |  | time between the client and server, are concerns. This includes |
| server. This includes the possibility of race conditions if the |  | the possibility of race conditions if the document has changed |
| document has changed between the time it was first requested and |  | between the time it was first requested and the If-Modified-Since |
| the If-Modified-Since date of a subsequent request, and the |  | date of a subsequent request, and the possibility of clock-skew- |
| possibility of clock-skew-related problems if the If-Modified- |  | related problems if the If-Modified-Since date is derived from the |
| Since date is derived from the client's clock without correction |  | client's clock without correction to the server's clock. |
| to the server's clock. Corrections for different time bases |  | Corrections for different time bases between client and server are |
| between client and server are at best approximate due to network |  | at best approximate due to network latency. |
| latency. |  |  |
| The result of a request having both an If-Modified-Since header field |  | The result of a request having both an If-Modified-Since header field |
| and either an If-Match or an If-Unmodified-Since header fields is |  | and either an If-Match or an If-Unmodified-Since header fields is |
| undefined by this specification. |  | undefined by this specification. |
| 6.4. If-None-Match |  | 6.4. If-None-Match |
| The "If-None-Match" request-header field is used to make a request |  | The "If-None-Match" request-header field is used to make a request |
| method conditional. A client that has one or more entities |  | method conditional. A client that has one or more representations |
| previously obtained from the resource can verify that none of those |  | previously obtained from the resource can verify that none of those |
| entities is current by including a list of their associated entity |  | representations is current by including a list of their associated |
| tags in the If-None-Match header field. |  | entity-tags in the If-None-Match header field. |
| This allows efficient updates of cached information with a minimum |  | This allows efficient updates of cached information with a minimum |
| amount of transaction overhead. It is also used to prevent a method |  | amount of transaction overhead. It is also used to prevent a method |
| (e.g., PUT) from inadvertently modifying an existing resource when |  | (e.g., PUT) from inadvertently modifying an existing resource when |
| the client believes that the resource does not exist. |  | the client believes that the resource does not exist. |
| As a special case, the value "*" matches any current entity of the |  | As a special case, the value "*" matches any current representation |
| resource. |  | of the resource. |
| If-None-Match = "If-None-Match" ":" OWS If-None-Match-v |  | If-None-Match = "If-None-Match" ":" OWS If-None-Match-v |
| If-None-Match-v = "*" / 1#entity-tag |  | If-None-Match-v = "*" / 1#entity-tag |
| If any of the entity tags match the entity tag of the entity that |  | If any of the entity-tags match the entity-tag of the representation |
| would have been returned in the response to a similar GET request |  | that would have been returned in the response to a similar GET |
| (without the If-None-Match header) on that resource, or if "*" is |  | request (without the If-None-Match header) on that resource, or if |
| given and any current entity exists for that resource, then the |  | "*" is given and any current representation exists for that resource, |
| server MUST NOT perform the requested method, unless required to do |  | then the server MUST NOT perform the requested method, unless |
| so because the resource's modification date fails to match that |  | required to do so because the resource's modification date fails to |
| supplied in an If-Modified-Since header field in the request. |  | match that supplied in an If-Modified-Since header field in the |
| Instead, if the request method was GET or HEAD, the server SHOULD |  | request. Instead, if the request method was GET or HEAD, the server |
| respond with a 304 (Not Modified) response, including the cache- |  | SHOULD respond with a 304 (Not Modified) response, including the |
| related header fields (particularly ETag) of one of the entities that |  | cache-related header fields (particularly ETag) of one of the |
| matched. For all other request methods, the server MUST respond with |  | representations that matched. For all other request methods, the |
| a status of 412 (Precondition Failed). |  | server MUST respond with a 412 (Precondition Failed) status code. |
| If none of the entity tags match, then the server MAY perform the |  | If none of the entity-tags match, then the server MAY perform the |
| requested method as if the If-None-Match header field did not exist, |  | requested method as if the If-None-Match header field did not exist, |
| but MUST also ignore any If-Modified-Since header field(s) in the |  | but MUST also ignore any If-Modified-Since header field(s) in the |
| request. That is, if no entity tags match, then the server MUST NOT |  | request. That is, if no entity-tags match, then the server MUST NOT |
| return a 304 (Not Modified) response. |  | return a 304 (Not Modified) response. |
| If the request would, without the If-None-Match header field, result |  | If the request would, without the If-None-Match header field, result |
| in anything other than a 2xx or 304 status, then the If-None-Match |  | in anything other than a 2xx or 304 status code, then the If-None- |
| header MUST be ignored. (See Section 5 for a discussion of server |  | Match header MUST be ignored. (See Section 5 for a discussion of |
| behavior when both If-Modified-Since and If-None-Match appear in the |  | server behavior when both If-Modified-Since and If-None-Match appear |
| same request.) |  | in the same request.) |
| The meaning of "If-None-Match: *" is that the method MUST NOT be |  | The meaning of "If-None-Match: *" is that the method MUST NOT be |
| performed if the representation selected by the origin server (or by |  | performed if the representation selected by the origin server (or by |
| a cache, possibly using the Vary mechanism, see Section 3.5 of |  | a cache, possibly using the Vary mechanism, see Section 3.5 of |
| [Part6]) exists, and SHOULD be performed if the representation does |  | [Part6]) exists, and SHOULD be performed if the representation does |
| not exist. This feature is intended to be useful in preventing races |  | not exist. This feature is intended to be useful in preventing races |
| between PUT operations. |  | between PUT operations. |
| Examples: |  | Examples: |
| If-None-Match: "xyzzy" |  | If-None-Match: "xyzzy" |
| skipping to change at page 17, line 35 |  | skipping to change at page 17, line 26 |
| If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |  | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
| If-None-Match: * |  | If-None-Match: * |
| The result of a request having both an If-None-Match header field and |  | The result of a request having both an If-None-Match header field and |
| either an If-Match or an If-Unmodified-Since header fields is |  | either an If-Match or an If-Unmodified-Since header fields is |
| undefined by this specification. |  | undefined by this specification. |
| 6.5. If-Unmodified-Since |  | 6.5. If-Unmodified-Since |
| The "If-Unmodified-Since" request-header field is used to make a |  | The "If-Unmodified-Since" request-header field is used to make a |
| request method conditional. If the requested resource has not been |  | request method conditional. If the representation that would have |
| modified since the time specified in this field, the server SHOULD |  | been transferred in a 200 response to a GET request on the same |
| perform the requested operation as if the If-Unmodified-Since header |  | resource has not been modified since the time specified in this |
| were not present. |  | field, the server SHOULD perform the requested operation as if the |
|  |  | If-Unmodified-Since header were not present. |
| If the requested variant has been modified since the specified time, |  | If the representation has been modified since the specified time, the |
| the server MUST NOT perform the requested operation, and MUST return |  | server MUST NOT perform the requested operation, and MUST return a |
| a 412 (Precondition Failed). |  | 412 (Precondition Failed). |
| If-Unmodified-Since = "If-Unmodified-Since" ":" OWS |  | If-Unmodified-Since = "If-Unmodified-Since" ":" OWS |
| If-Unmodified-Since-v |  | If-Unmodified-Since-v |
| If-Unmodified-Since-v = HTTP-date |  | If-Unmodified-Since-v = HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| If the request normally (i.e., without the If-Unmodified-Since |  | If the request normally (i.e., without the If-Unmodified-Since |
| header) would result in anything other than a 2xx or 412 status, the |  | header) would result in anything other than a 2xx or 412 status code, |
| If-Unmodified-Since header SHOULD be ignored. |  | the If-Unmodified-Since header SHOULD be ignored. |
| If the specified date is invalid, the header is ignored. |  | If the specified date is invalid, the header is ignored. |
| The result of a request having both an If-Unmodified-Since header |  | The result of a request having both an If-Unmodified-Since header |
| field and either an If-None-Match or an If-Modified-Since header |  | field and either an If-None-Match or an If-Modified-Since header |
| fields is undefined by this specification. |  | fields is undefined by this specification. |
| 6.6. Last-Modified |  | 6.6. Last-Modified |
| The "Last-Modified" entity-header field indicates the date and time |  | The "Last-Modified" header field indicates the date and time at which |
| at which the origin server believes the variant was last modified. |  | the origin server believes the representation was last modified. |
| Last-Modified = "Last-Modified" ":" OWS Last-Modified-v |  | Last-Modified = "Last-Modified" ":" OWS Last-Modified-v |
| Last-Modified-v = HTTP-date |  | Last-Modified-v = HTTP-date |
| An example of its use is |  | An example of its use is |
| Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |  | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| The exact meaning of this header field depends on the implementation |  | The exact meaning of this header field depends on the implementation |
| of the origin server and the nature of the original resource. For |  | of the origin server and the nature of the original resource. For |
| files, it may be just the file system last-modified time. For |  | files, it might be just the file system last-modified time. For |
| entities with dynamically included parts, it may be the most recent |  | representations with dynamically included parts, it might be the most |
| of the set of last-modify times for its component parts. For |  | recent of the set of last-modify times for its component parts. For |
| database gateways, it may be the last-update time stamp of the |  | database gateways, it might be the last-update time stamp of the |
| record. For virtual objects, it may be the last time the internal |  | record. For virtual objects, it might be the last time the internal |
| state changed. |  | state changed. |
| An origin server MUST NOT send a Last-Modified date which is later |  | An origin server MUST NOT send a Last-Modified date which is later |
| than the server's time of message origination. In such cases, where |  | than the server's time of message origination. In such cases, where |
| the resource's last modification would indicate some time in the |  | the resource's last modification would indicate some time in the |
| future, the server MUST replace that date with the message |  | future, the server MUST replace that date with the message |
| origination date. |  | origination date. |
| An origin server SHOULD obtain the Last-Modified value of the entity |  | An origin server SHOULD obtain the Last-Modified value of the |
| as close as possible to the time that it generates the Date value of |  | representation as close as possible to the time that it generates the |
| its response. This allows a recipient to make an accurate assessment |  | Date value of its response. This allows a recipient to make an |
| of the entity's modification time, especially if the entity changes |  | accurate assessment of the representation's modification time, |
| near the time that the response is generated. |  | especially if the representation changes near the time that the |
|  |  | response is generated. |
| HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |  | HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |
| The Last-Modified entity-header field value is often used as a cache |  | The Last-Modified header field value is often used as a cache |
| validator. In simple terms, a cache entry is considered to be valid |  | validator. In simple terms, a cache entry is considered to be valid |
| if the entity has not been modified since the Last-Modified value. |  | if the representation has not been modified since the Last-Modified |
|  |  | value. |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. Status Code Registration |  | 7.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> should 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 3.1 | |
| | 412 | Precondition Failed | Section 3.2 | |  | | 412 | Precondition Failed | Section 3.2 | |
| +-------+---------------------+-------------+ |  | +-------+---------------------+-------------+ |
| 7.2. Message Header Registration |  | 7.2. Header Field Registration |
| The Message Header 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> should 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 6.1 | |
| | If-Match | http | standard | Section 6.2 | |  | | If-Match | http | standard | Section 6.2 | |
| | If-Modified-Since | http | standard | Section 6.3 | |  | | If-Modified-Since | http | standard | Section 6.3 | |
| | If-None-Match | http | standard | Section 6.4 | |  | | If-None-Match | http | standard | Section 6.4 | |
| | If-Unmodified-Since | http | standard | Section 6.5 | |  | | If-Unmodified-Since | http | standard | Section 6.5 | |
| skipping to change at page 20, line 5 |  | skipping to change at page 19, line 51 |
| 9. Acknowledgments |  | 9. Acknowledgments |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-10 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-11 |
| (work in progress), July 2010. |  | (work in progress), August 2010. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-10 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-11 |
| (work in progress), July 2010. |  | (work in progress), August 2010. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-10 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-11 (work |
| in progress), July 2010. |  | in progress), August 2010. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-10 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-11 (work in |
| progress), July 2010. |  | progress), August 2010. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 10.2. Informative References |  | 10.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| Appendix A. Compatibility with Previous Versions |  | Appendix A. Changes from RFC 2616 |
| A.1. Changes from RFC 2616 |  |  |
| Allow weak entity tags in all requests except range requests |  | Allow weak entity-tags in all requests except range requests |
| (Sections 4 and 6.4). |  | (Sections 4 and 6.4). |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| ETag = "ETag:" OWS ETag-v |  | ETag = "ETag:" OWS ETag-v |
| ETag-v = 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 = "If-Match:" OWS If-Match-v |
| skipping to change at page 24, line 5 |  | skipping to change at page 24, line 5 |
| registrations for optional status codes" |  | registrations for optional status codes" |
| C.10. Since draft-ietf-httpbis-p4-conditional-08 |  | C.10. Since draft-ietf-httpbis-p4-conditional-08 |
| No significant changes. |  | No significant changes. |
| C.11. Since draft-ietf-httpbis-p4-conditional-09 |  | C.11. Since draft-ietf-httpbis-p4-conditional-09 |
| No significant changes. |  | No significant changes. |
|  |  | C.12. Since draft-ietf-httpbis-p4-conditional-10 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |
|  |  | 'Requested Variant'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |
|  |  | entity / representation / variant terminology" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
|  |  | removing the 'changes from 2068' sections" |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 7 |  | 304 Not Modified (status code) 7 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 8 |  | 412 Precondition Failed (status code) 7 |
| E |  | E |
| ETag header 13 |  | ETag header 12 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 5 |  | entity-tag 5 |
| ETag 13 |  | ETag 12 |
| ETag-v 13 |  | ETag-v 12 |
| If-Match 13 |  | If-Match 13 |
| If-Match-v 13 |  | If-Match-v 13 |
| If-Modified-Since 15 |  | If-Modified-Since 14 |
| If-Modified-Since-v 15 |  | If-Modified-Since-v 14 |
| If-None-Match 16 |  | If-None-Match 16 |
| If-None-Match-v 16 |  | If-None-Match-v 16 |
| If-Unmodified-Since 17 |  | If-Unmodified-Since 17 |
| If-Unmodified-Since-v 17 |  | If-Unmodified-Since-v 17 |
| Last-Modified 18 |  | Last-Modified 18 |
| Last-Modified-v 18 |  | Last-Modified-v 18 |
| opaque-tag 5 |  | opaque-tag 5 |
| weak 5 |  | weak 5 |
| H |  | H |
| Headers |  | Headers |
| ETag 13 |  | ETag 12 |
| If-Match 13 |  | If-Match 13 |
| If-Modified-Since 14 |  | If-Modified-Since 14 |
| If-None-Match 16 |  | If-None-Match 16 |
| If-Unmodified-Since 17 |  | If-Unmodified-Since 17 |
| Last-Modified 18 |  | Last-Modified 18 |
| I |  | I |
| If-Match header 13 |  | If-Match header 13 |
| If-Modified-Since header 14 |  | If-Modified-Since header 14 |
| If-None-Match header 16 |  | If-None-Match header 16 |
| If-Unmodified-Since header 17 |  | If-Unmodified-Since header 17 |
| L |  | L |
| Last-Modified header 18 |  | Last-Modified header 18 |
| S |  | S |
| Status Codes |  | Status Codes |
| 304 Not Modified 7 |  | 304 Not Modified 7 |
| 412 Precondition Failed 8 |  | 412 Precondition Failed 7 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 102 change blocks.
| 265 lines changed or deleted |  | 277 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/