| draft-ietf-httpbis-p4-conditional-02.txt |  | draft-ietf-httpbis-p4-conditional-03.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: August 27, 2008 J. Mogul |  | Expires: December 19, 2008 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 |
| February 24, 2008 |  | June 17, 2008 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-02 |  | draft-ietf-httpbis-p4-conditional-03 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 49 |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on August 27, 2008. |  | This Internet-Draft will expire on December 19, 2008. |
| Copyright Notice |  |  |
| Copyright (C) The IETF Trust (2008). |  |  |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 4 of the |  | information initiative since 1990. This document is Part 4 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |
| request header fields for indicating conditional requests and the |  | request header fields for indicating conditional requests and the |
| rules for constructing responses to those requests. |  | rules for constructing responses to those requests. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://www.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
| This draft incorporates those issue resolutions that were either |  | The changes in this draft are summarized in Appendix B.4. |
| collected in the original RFC2616 errata list |  |  |
| (<http://purl.org/NET/http-errata>), or which were agreed upon on the |  |  |
| mailing list between October 2006 and November 2007 (as published in |  |  |
| "draft-lafon-rfc2616bis-03"). |  |  |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 |
| 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |
| 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |  | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |
| 5. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 |  | 5. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 |
| 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |  | 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |
| 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |  | 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |
| 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |  | 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |
| 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |  | 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 15 |
| 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |
|  |  | 8.1. Message Header Registration . . . . . . . . . . . . . . . 17 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 18 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 18 |
| A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 |  | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 18 |  | publication) . . . . . . . . . . . . . . . . . . . . 19 |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 18 |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 |
| B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 18 |  | B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19 |
| B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 18 |  | B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19 |
|  |  | B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 23 |  | Intellectual Property and Copyright Statements . . . . . . . . . . 24 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 response metadata for indicating |  | This document defines HTTP/1.1 response metadata for indicating |
| potential changes to payload content, including modification time |  | potential changes to payload content, including modification time |
| stamps and opaque entity-tags, and the HTTP conditional request |  | stamps and opaque entity-tags, and the HTTP conditional request |
| mechanisms that allow preconditions to be placed on a request method. |  | mechanisms that allow preconditions to be placed on a request method. |
| Conditional GET requests allow for efficient cache updates. Other |  | Conditional GET requests allow for efficient cache updates. Other |
| conditional request methods are used to protect against overwriting |  | conditional request methods are used to protect against overwriting |
| or misunderstanding the state of a resource that has been changed |  | or misunderstanding the state of a resource that has been changed |
| skipping to change at page 7, line 40 |  | skipping to change at page 7, line 40 |
| 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 an |
| entity. For example, either kind is usable for a conditional GET of |  | entity. For example, either kind is usable for a conditional GET of |
| a full entity. However, only a strong validator is usable for a sub- |  | a full entity. However, only a strong validator is usable for a sub- |
| range retrieval, since otherwise the client might end up with an |  | range retrieval, since otherwise the client might end up with an |
| internally inconsistent entity. |  | internally inconsistent entity. |
| Clients MAY issue simple (non-subrange) GET requests with either weak |  | Clients MUST NOT use weak validators in range requests ([Part5]). |
| validators or strong validators. Clients MUST NOT use weak |  |  |
| validators in other forms of request. |  |  |
| 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 validators MUST be identical in every way, and both MUST NOT |  | both validators MUST be identical in every way, and both MUST NOT |
| be weak. |  | be weak. |
| o The weak comparison function: in order to be considered equal, |  | o The weak comparison function: in order to be considered equal, |
| skipping to change at page 9, line 12 |  | skipping to change at page 9, line 10 |
| Modified values are generated from different clocks, or at somewhat |  | Modified values are generated from different clocks, or at somewhat |
| different times during the preparation of the response. An |  | different times during the preparation of the response. An |
| implementation MAY use a value larger than 60 seconds, if it is |  | implementation MAY use a value larger than 60 seconds, if it is |
| believed that 60 seconds is too short. |  | believed that 60 seconds is too short. |
| If a client wishes to perform a sub-range retrieval on a value for |  | 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 |  | 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 |  | MAY do this only if the Last-Modified time is strong in the sense |
| described here. |  | described here. |
| A cache or origin server receiving a conditional request, other than |  | A cache or origin server receiving a conditional range request |
| a full-body GET request, MUST use the strong comparison function to |  | ([Part5]) MUST use the strong comparison function to evaluate the |
| evaluate the condition. |  | condition. |
| These rules allow HTTP/1.1 caches and clients to safely perform sub- |  | These rules allow HTTP/1.1 caches and clients to safely perform sub- |
| range retrievals on values that have been obtained from HTTP/1.0 |  | range retrievals on values that have been obtained from HTTP/1.0 |
| servers. |  | servers. |
| 6. Rules for When to Use Entity Tags and Last-Modified Dates |  | 6. 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. |
| skipping to change at page 15, line 16 |  | skipping to change at page 15, line 11 |
| given and any current entity exists for that resource, then the |  | given and any current entity exists for that resource, then the |
| server MUST NOT perform the requested method, unless required to do |  | server MUST NOT perform the requested method, unless required to do |
| so because the resource's modification date fails to match that |  | so because the resource's modification date fails to match that |
| supplied in an If-Modified-Since header field in the request. |  | supplied in an If-Modified-Since header field in the request. |
| Instead, if the request method was GET or HEAD, the server SHOULD |  | Instead, if the request method was GET or HEAD, the server SHOULD |
| respond with a 304 (Not Modified) response, including the cache- |  | respond with a 304 (Not Modified) response, including the cache- |
| related header fields (particularly ETag) of one of the entities that |  | related header fields (particularly ETag) of one of the entities that |
| matched. For all other request methods, the server MUST respond with |  | matched. For all other request methods, the server MUST respond with |
| a status of 412 (Precondition Failed). |  | a status of 412 (Precondition Failed). |
| See Section 5 for rules on how to determine if two entities tags |  | See Section 5 for rules on how to determine if two entity tags match. |
| match. The weak comparison function can only be used with GET or |  |  |
| HEAD requests. |  |  |
| If none of the entity tags match, then the server MAY perform the |  | If none of the entity tags match, then the server MAY perform the |
| requested method as if the If-None-Match header field did not exist, |  | requested method as if the If-None-Match header field did not exist, |
| but MUST also ignore any If-Modified-Since header field(s) in the |  | but MUST also ignore any If-Modified-Since header field(s) in the |
| request. That is, if no entity tags match, then the server MUST NOT |  | request. That is, if no entity tags match, then the server MUST NOT |
| return a 304 (Not Modified) response. |  | return a 304 (Not Modified) response. |
| If the request would, without the If-None-Match header field, result |  | If the request would, without the If-None-Match header field, result |
| in anything other than a 2xx or 304 status, then the If-None-Match |  | in anything other than a 2xx or 304 status, then the If-None-Match |
| header MUST be ignored. (See Section 6 for a discussion of server |  | header MUST be ignored. (See Section 6 for a discussion of server |
| skipping to change at page 17, line 25 |  | skipping to change at page 17, line 16 |
| near the time that the response is generated. |  | near the time that the response is generated. |
| HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |  | HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. |
| The Last-Modified entity-header field value is often used as a cache |  | The Last-Modified entity-header field value is often used as a cache |
| validator. In simple terms, a cache entry is considered to be valid |  | validator. In simple terms, a cache entry is considered to be valid |
| if the entity has not been modified since the Last-Modified value. |  | if the entity has not been modified since the Last-Modified value. |
| 8. IANA Considerations |  | 8. IANA Considerations |
| [[anchor2: TBD.]] |  | 8.1. Message Header Registration |
|  |  | The Message Header Registry located at <http://www.iana.org/ |
|  |  | assignments/message-headers/message-header-index.html> should be |
|  |  | updated with the permanent registrations below (see [RFC3864]): |
|  |  | +---------------------+----------+----------+-------------+ |
|  |  | | Header Field Name | Protocol | Status | Reference | |
|  |  | +---------------------+----------+----------+-------------+ |
|  |  | | ETag | http | standard | Section 7.1 | |
|  |  | | If-Match | http | standard | Section 7.2 | |
|  |  | | If-Modified-Since | http | standard | Section 7.3 | |
|  |  | | If-None-Match | http | standard | Section 7.4 | |
|  |  | | If-Unmodified-Since | http | standard | Section 7.5 | |
|  |  | | Last-Modified | http | standard | Section 7.6 | |
|  |  | +---------------------+----------+----------+-------------+ |
|  |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
|  |  | Engineering Task Force". |
| 9. Security Considerations |  | 9. Security Considerations |
| No additional security considerations have been identified beyond |  | No additional security considerations have been identified beyond |
| those applicable to HTTP in general [Part1]. |  | those applicable to HTTP in general [Part1]. |
| 10. Acknowledgments |  | 10. Acknowledgments |
| 11. References |  | 11. References |
| 11.1. Normative References |  | 11.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-02 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-03 |
| (work in progress), February 2008. |  | (work in progress), June 2008. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-02 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-03 (work |
| in progress), February 2008. |  | in progress), June 2008. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-02 (work in progress), |  | draft-ietf-httpbis-p6-cache-03 (work in progress), |
| February 2008. |  | June 2008. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 11.2. Informative References |  | 11.2. Informative References |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
| RFC 2068, January 1997. |  | RFC 2068, January 1997. |
| [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 |
|  |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
|  |  | September 2004. |
| Appendix A. Compatibility with Previous Versions |  | Appendix A. Compatibility with Previous Versions |
| A.1. Changes from RFC 2616 |  | A.1. Changes from RFC 2616 |
|  |  | Allow weak entity tags in all requests except range requests |
|  |  | (Sections 5 and 7.4). |
| Appendix B. Change Log (to be removed by RFC Editor before publication) |  | Appendix B. Change Log (to be removed by RFC Editor before publication) |
| B.1. Since RFC2616 |  | B.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| B.2. Since draft-ietf-httpbis-p4-conditional-00 |  | B.2. Since draft-ietf-httpbis-p4-conditional-00 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 19, line 8 |  | skipping to change at page 19, line 30 |
| o Move definitions of 304 and 412 condition codes from Part2. |  | o Move definitions of 304 and 412 condition codes from Part2. |
| B.3. Since draft-ietf-httpbis-p4-conditional-01 |  | B.3. Since draft-ietf-httpbis-p4-conditional-01 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
|  |  | B.4. Since draft-ietf-httpbis-p4-conditional-02 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak |
|  |  | ETags on non-GET requests" |
|  |  | Ongoing work on IANA Message Header Registration |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): |
|  |  | o Reference RFC 3984, and update header registrations for headers |
|  |  | defined in this document. |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 5 |  | 304 Not Modified (status code) 5 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 6 |  | 412 Precondition Failed (status code) 6 |
| E |  | E |
| ETag header 11 |  | ETag header 11 |
| skipping to change at page 19, line 34 |  | skipping to change at page 20, line 21 |
| If-Modified-Since 13 |  | If-Modified-Since 13 |
| If-None-Match 14 |  | If-None-Match 14 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 16 |
| Last-Modified 16 |  | Last-Modified 16 |
| opaque-tag 5 |  | opaque-tag 5 |
| weak 5 |  | weak 5 |
| H |  | H |
| Headers |  | Headers |
| ETag 11 |  | ETag 11 |
| If-Match 12 |  | If-Match 11 |
| If-Modified-Since 13 |  | If-Modified-Since 13 |
| If-None-Match 14 |  | If-None-Match 14 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 15 |
| Last-Modified 16 |  | Last-Modified 16 |
| I |  | I |
| If-Match header 12 |  | If-Match header 11 |
| If-Modified-Since header 13 |  | If-Modified-Since header 13 |
| If-None-Match header 14 |  | If-None-Match header 14 |
| If-Unmodified-Since header 16 |  | If-Unmodified-Since header 15 |
| L |  | L |
| Last-Modified header 16 |  | Last-Modified header 16 |
| S |  | S |
| Status Codes |  | Status Codes |
| 304 Not Modified 5 |  | 304 Not Modified 5 |
| 412 Precondition Failed 6 |  | 412 Precondition Failed 6 |
| Authors' Addresses |  | Authors' Addresses |
| skipping to change at page 23, line 44 |  | skipping to change at line 1018 |
| attempt made to obtain a general license or permission for the use of |  | attempt made to obtain a general license or permission for the use of |
| such proprietary rights by implementers or users of this |  | such proprietary rights by implementers or users of this |
| specification can be obtained from the IETF on-line IPR repository at |  | specification can be obtained from the IETF on-line IPR repository at |
| http://www.ietf.org/ipr. |  | http://www.ietf.org/ipr. |
| The IETF invites any interested party to bring to its attention any |  | The IETF invites any interested party to bring to its attention any |
| copyrights, patents or patent applications, or other proprietary |  | copyrights, patents or patent applications, or other proprietary |
| rights that may cover technology that may be required to implement |  | rights that may cover technology that may be required to implement |
| this standard. Please address the information to the IETF at |  | this standard. Please address the information to the IETF at |
| ietf-ipr@ietf.org. |  | ietf-ipr@ietf.org. |
| Acknowledgment |  |  |
| Funding for the RFC Editor function is provided by the IETF |  |  |
| Administrative Support Activity (IASA). |  |  |
End of changes. 26 change blocks.
| 42 lines changed or deleted |  | 70 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/