| draft-ietf-httpbis-p4-conditional-08.txt |  | draft-ietf-httpbis-p4-conditional-09.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 One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: April 29, 2010 J. Mogul |  | Expires: September 9, 2010 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 |
| October 26, 2009 |  | March 8, 2010 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-08 |  | draft-ietf-httpbis-p4-conditional-09 |
|  |  | Abstract |
|  |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
|  |  | protocol for distributed, collaborative, hypermedia information |
|  |  | systems. HTTP has been in use by the World Wide Web global |
|  |  | information initiative since 1990. This document is Part 4 of the |
|  |  | seven-part specification that defines the protocol referred to as |
|  |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |
|  |  | request header fields for indicating conditional requests and the |
|  |  | rules for constructing responses to those requests. |
|  |  | Editorial Note (To be removed by RFC Editor) |
|  |  | Discussion of this draft should take place on the HTTPBIS working |
|  |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
|  |  | at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related |
|  |  | documents (including fancy diffs) can be found at |
|  |  | <http://tools.ietf.org/wg/httpbis/>. |
|  |  | The changes in this draft are summarized in Appendix C.10. |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted to IETF in full conformance with the |
| provisions of BCP 78 and BCP 79. This document may contain material |  | provisions of BCP 78 and BCP 79. |
| from IETF Documents or IETF Contributions published or made publicly |  |  |
| available before November 10, 2008. The person(s) controlling the |  |  |
| copyright in some of this material may not have granted the IETF |  |  |
| Trust the right to allow modifications of such material outside the |  |  |
| IETF Standards Process. Without obtaining an adequate license from |  |  |
| the person(s) controlling the copyright in such materials, this |  |  |
| document may not be modified outside the IETF Standards Process, and |  |  |
| derivative works of it may not be created outside the IETF Standards |  |  |
| Process, except to format it for publication as an RFC or to |  |  |
| translate it into languages other than English. |  |  |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| skipping to change at page 2, line 4 |  | skipping to change at page 2, line 15 |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on April 29, 2010. |  | This Internet-Draft will expire on September 9, 2010. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2009 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 in effect on the date of |  | Provisions Relating to IETF Documents |
| publication of this document (http://trustee.ietf.org/license-info). |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| Please review these documents carefully, as they describe your rights |  | publication of this document. Please review these documents |
| and restrictions with respect to this document. |  | carefully, as they describe your rights and restrictions with respect |
|  |  | to this document. Code Components extracted from this document must |
| Abstract |  | include Simplified BSD License text as described in Section 4.e of |
|  |  | the Trust Legal Provisions and are provided without warranty as |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | described in the BSD License. |
| protocol for distributed, collaborative, hypermedia information |  |  |
| systems. HTTP has been in use by the World Wide Web global |  |  |
| information initiative since 1990. This document is Part 4 of the |  |  |
| seven-part specification that defines the protocol referred to as |  |  |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |  |  |
| request header fields for indicating conditional requests and the |  |  |
| rules for constructing responses to those requests. |  |  |
| Editorial Note (To be removed by RFC Editor) |  |  |
| Discussion of this draft should take place on the HTTPBIS working |  |  |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  |  |
| at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related |  |  |
| documents (including fancy diffs) can be found at |  |  |
| <http://tools.ietf.org/wg/httpbis/>. |  |  |
| The changes in this draft are summarized in Appendix C.9. |  | This document may contain material from IETF Documents or IETF |
|  |  | Contributions published or made publicly available before November |
|  |  | 10, 2008. The person(s) controlling the copyright in some of this |
|  |  | material may not have granted the IETF Trust the right to allow |
|  |  | modifications of such material outside the IETF Standards Process. |
|  |  | Without obtaining an adequate license from the person(s) controlling |
|  |  | the copyright in such materials, this document may not be modified |
|  |  | outside the IETF Standards Process, and derivative works of it may |
|  |  | not be created outside the IETF Standards Process, except to format |
|  |  | it for publication as an RFC or to translate it into languages other |
|  |  | than English. |
| 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 |
| skipping to change at page 3, line 48 |  | skipping to change at page 3, line 48 |
| publication) . . . . . . . . . . . . . . . . . . . . 20 |  | publication) . . . . . . . . . . . . . . . . . . . . 20 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 |
| C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21 |  | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21 |
| C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21 |  | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21 |
| C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21 |  | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21 |
| C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21 |  | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21 |
| C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22 |  | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22 |
| C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22 |  | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22 |
| C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22 |  | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22 |
| C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22 |  | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22 |
|  |  | C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 22 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 10, line 22 |  | skipping to change at page 10, line 22 |
| 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 entity changes in any way. A weak entity tag SHOULD |
| change whenever the associated entity changes in a semantically |  | change whenever the associated entity changes in a semantically |
| significant way. |  | 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 entities, or reusing a specific weak |
| entity tag value for two semantically different entities. Cache |  | entity tag value for two semantically different entities. Cache |
| entries might persist for arbitrarily long periods, regardless of |  | entries might persist for arbitrarily long periods, regardless of |
| expiration times, so it might be inappropriate to expect that a |  | expiration times, so it might be inappropriate to expect that a |
| cache will never again attempt to validate an entry using a |  | cache will never again attempt to validate an entry using a |
| validator that it obtained at some point in the past. |  | validator that it obtained at some point in the past. |
| HTTP/1.1 clients: |  | HTTP/1.1 clients: |
| o If an entity tag has been provided by the origin server, MUST use |  | o MUST use that entity tag in any cache-conditional request (using |
| that entity tag in any cache-conditional request (using If-Match |  | If-Match or If-None-Match) if an entity tag has been provided by |
| or If-None-Match). |  | the origin server. |
| o If only a Last-Modified value has been provided by the origin |  | o SHOULD use the Last-Modified value in non-subrange cache- |
| server, SHOULD use that value in non-subrange cache-conditional |  | conditional requests (using If-Modified-Since) if only a Last- |
| requests (using If-Modified-Since). |  | Modified value has been provided by the origin server. |
| o If only a Last-Modified value has been provided by an HTTP/1.0 |  | o MAY use the Last-Modified value in subrange cache-conditional |
| origin server, MAY use that value in subrange cache-conditional |  | requests (using If-Unmodified-Since) if only a Last-Modified value |
| requests (using If-Unmodified-Since:). The user agent SHOULD |  | has been provided by an HTTP/1.0 origin server. The user agent |
| provide a way to disable this, in case of difficulty. |  | SHOULD provide a way to disable this, in case of difficulty. |
| o If both an entity tag and a Last-Modified value have been provided |  | o SHOULD use both validators in cache-conditional requests if both |
| by the origin server, SHOULD use both validators in cache- |  | an entity tag and a Last-Modified value have been provided by the |
| conditional requests. This allows both HTTP/1.0 and HTTP/1.1 |  | origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to |
| 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 of 304 (Not Modified) |
| unless doing so is consistent with all of the conditional header |  | unless doing so is consistent with all of the conditional header |
| fields in the request. |  | 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 |
| skipping to change at page 15, line 17 |  | skipping to change at page 15, line 17 |
| 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 entities |
| previously obtained from the resource can verify that none of those |  | previously obtained from the resource can verify that none of those |
| entities is current by including a list of their associated entity |  | entities is current by including a list of their associated entity |
| tags in the If-None-Match header field. |  | 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 entity of the |
| resource. |  | 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 entity that |
| would have been returned in the response to a similar GET request |  | would have been returned in the response to a similar GET request |
| skipping to change at page 18, line 46 |  | skipping to change at page 18, line 46 |
| 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-08 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-09 |
| (work in progress), October 2009. |  | (work in progress), March 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-08 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-09 (work |
| in progress), October 2009. |  | in progress), March 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-08 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in |
| progress), October 2009. |  | progress), March 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., |
| skipping to change at page 22, line 44 |  | skipping to change at page 22, line 44 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on |
| non-GET requests" (If-Match still was defined to require strong |  | non-GET requests" (If-Match still was defined to require strong |
| matching) |  | matching) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |
| registrations for optional status codes" |  | registrations for optional status codes" |
|  |  | C.10. Since draft-ietf-httpbis-p4-conditional-08 |
|  |  | No significant changes. |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 6 |  | 304 Not Modified (status code) 6 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 6 |  | 412 Precondition Failed (status code) 6 |
| E |  | E |
| ETag header 11 |  | ETag header 11 |
End of changes. 21 change blocks.
| 63 lines changed or deleted |  | 75 lines changed or added |
This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/