| draft-ietf-httpbis-p4-conditional-00.txt |  | draft-ietf-httpbis-p4-conditional-01.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2068, 2616 J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| (if approved) One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Intended status: Standards Track J. Mogul |  | Expires: July 15, 2008 J. Mogul |
| Expires: June 22, 2008 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 |
| December 20, 2007 |  | Y. Lafon, Ed. |
|  |  | W3C |
|  |  | J. Reschke, Ed. |
|  |  | greenbytes |
|  |  | January 12, 2008 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-00 |  | draft-ietf-httpbis-p4-conditional-01 |
| 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 45 |  | 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 June 22, 2008. |  | This Internet-Draft will expire on July 15, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | 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) |
| This version of the HTTP specification contains only minimal |  |  |
| editorial changes from [RFC2616] (abstract, introductory paragraph, |  |  |
| and authors' addresses). All other changes are due to partitioning |  |  |
| the original into seven mostly independent parts. The intent is for |  |  |
| readers of future drafts to able to use draft 00 as the basis for |  |  |
| comparison when the WG makes later changes to the specification text. |  |  |
| This draft will shortly be followed by draft 01 (containing the first |  |  |
| round of changes that have already been agreed to on the mailing |  |  |
| list). There is no point in reviewing this draft other than to |  |  |
| verify that the partitioning has been done correctly. Roy T. |  |  |
| Fielding, Yves Lafon, and Julian Reschke will be the editors after |  |  |
| draft 00 is submitted. |  |  |
| 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://www3.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://www3.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
|  |  | This draft incorporates those issue resolutions that were either |
|  |  | 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 |
| 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 4 |  | 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |
| 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 5 |  | 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |
| 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 5 |  | 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 |
| 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 8 |  | 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10 |
| 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 11 |  | 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 12 |
| 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 13 |  | 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |
| 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 14 |  | 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 15 |
| 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 15 |  | 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 20 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 17 |
|  |  | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17 |
|  |  | Appendix B. Change Log (to be removed by RFC Editor before |
|  |  | publication) . . . . . . . . . . . . . . . . . . . . 17 |
|  |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17 |
|  |  | B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 18 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 22 |
| 1. Introduction |  | 1. Introduction |
| This document will define aspects of HTTP related to conditional |  | This document defines HTTP/1.1 response metadata for indicating |
| request messages based on time stamps and entity-tags. Right now it |  | potential changes to payload content, including modification time |
| only includes the extracted relevant sections of RFC 2616 [RFC2616] |  | stamps and opaque entity-tags, and the HTTP conditional request |
| without edit. |  | mechanisms that allow preconditions to be placed on a request method. |
|  |  | Conditional GET requests allow for efficient cache updates. Other |
|  |  | conditional request methods are used to protect against overwriting |
|  |  | or misunderstanding the state of a resource that has been changed |
|  |  | unbeknownst to the requesting client. |
|  |  | This document is currently disorganized in order to minimize the |
|  |  | changes between drafts and enable reviewers to see the smaller errata |
|  |  | changes. The next draft will reorganize the sections to better |
|  |  | reflect the content. In particular, the sections on resource |
|  |  | metadata will be discussed first and then followed by each |
|  |  | conditional request-header, concluding with a definition of |
|  |  | precedence and the expectation of ordering strong validator checks |
|  |  | before weak validator checks. It is likely that more content from |
|  |  | [Part6] will migrate to this part, where appropriate. The current |
|  |  | mess reflects how widely dispersed these topics and associated |
|  |  | requirements had become in [RFC2616]. |
|  |  | 1.1. Requirements |
|  |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|  |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
|  |  | document are to be interpreted as described in [RFC2119]. |
|  |  | An implementation is not compliant if it fails to satisfy one or more |
|  |  | of the MUST or REQUIRED level requirements for the protocols it |
|  |  | implements. An implementation that satisfies all the MUST or |
|  |  | REQUIRED level and all the SHOULD level requirements for its |
|  |  | protocols is said to be "unconditionally compliant"; one that |
|  |  | satisfies all the MUST level requirements but not all the SHOULD |
|  |  | level requirements for its protocols is said to be "conditionally |
|  |  | compliant." |
| 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 entities from the same |
| requested resource. HTTP/1.1 uses entity tags in the ETag |  | requested resource. HTTP/1.1 uses entity tags in the ETag |
| (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4), |  | (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4), |
| and If-Range (Section 5.3 of [Part5]) header fields. The definition |  | and If-Range (Section 5.3 of [Part5]) header fields. The definition |
| of how they are used and compared as cache validators is in |  | of how they are used and compared as cache validators is in |
| Section 4. An entity tag consists of an opaque quoted string, |  | Section 4. An entity tag consists of an opaque quoted string, |
| possibly prefixed by a weakness indicator. |  | possibly prefixed by a weakness indicator. |
| skipping to change at page 5, line 11 |  | skipping to change at page 5, line 40 |
| 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: |  | The response MUST include the following header fields: |
| o Date, unless its omission is required by Section 8.3.1 of [Part1] |  | o Date, unless its omission is required by Section 8.3.1 of [Part1] |
| If a clockless origin server obeys these rules, and proxies and |  | If a clockless origin server obeys these rules, and proxies and |
| clients add their own Date to any response received without one (as |  | clients add their own Date to any response received without one (as |
| already specified by [RFC2068], section 14.19), caches will operate |  | already specified by [RFC2068], Section 14.19), caches will operate |
| correctly. |  | correctly. |
| o ETag and/or Content-Location, if the header would have been sent |  | o ETag and/or Content-Location, if the header would have been sent |
| in a 200 response to the same request |  | in a 200 response to the same request |
| o Expires, Cache-Control, and/or Vary, if the field-value might |  | o Expires, Cache-Control, and/or Vary, if the field-value might |
| differ from that sent in any previous response for the same |  | differ from that sent in any previous response for the same |
| variant |  | variant |
| If the conditional GET used a strong cache validator (see [Part6]), |  | If the conditional GET used a strong cache validator (see Section 4), |
| the response SHOULD NOT include other entity-headers. Otherwise |  | the response SHOULD NOT include other entity-headers. Otherwise |
| (i.e., the conditional GET used a weak validator), the response MUST |  | (i.e., the conditional GET used a weak validator), the response MUST |
| NOT include other entity-headers; this prevents inconsistencies |  | NOT include other entity-headers; this prevents inconsistencies |
| between cached entity-bodies and updated headers. |  | between cached entity-bodies and updated headers. |
| If a 304 response indicates an entity not currently cached, then the |  | If a 304 response indicates an entity not currently cached, then the |
| cache MUST disregard the response and repeat the request without the |  | cache MUST 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 |
| skipping to change at page 10, line 15 |  | skipping to change at page 10, line 46 |
| 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 all standard |  | This section defines the syntax and semantics of HTTP/1.1 header |
| HTTP/1.1 header fields. For entity-header fields, both sender and |  | fields related to conditional requests. |
| recipient refer to either the client or the server, depending on who |  |  |
| sends and who receives the entity. |  | 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 for the requested variant. The headers used with entity |  | entity tag for the requested variant. The headers used with entity |
| tags are described in sections 6.2, 6.4 and Section 5.3 of [Part5]. |  | tags are described in Sections 6.2 and 6.4 of this document, and in |
| The entity tag MAY be used for comparison with other entities from |  | Section 5.3 of [Part5]. The entity tag MAY be used for comparison |
| the same resource (see Section 4). |  | with other entities from the same resource (see Section 4). |
| ETag = "ETag" ":" entity-tag |  | ETag = "ETag" ":" entity-tag |
| Examples: |  | Examples: |
| ETag: "xyzzy" |  | ETag: "xyzzy" |
| ETag: W/"xyzzy" |  | ETag: W/"xyzzy" |
| ETag: "" |  | ETag: "" |
| 6.2. If-Match |  | 6.2. If-Match |
| skipping to change at page 11, line 26 |  | skipping to change at page 12, line 12 |
| most useful when the client wants to prevent an updating method, such |  | most useful when the client wants to prevent an updating method, such |
| as PUT, from modifying a resource that has changed since the client |  | as PUT, from modifying a resource that has changed since the client |
| last retrieved it. |  | 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, then the If-Match header |
| MUST be ignored. |  | 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 15.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 entity corresponding to the If-Match value (a single |
| entity tag) is no longer a representation of that resource. This |  | entity tag) is no longer a representation of that resource. This |
| allows the user to indicate that they do not wish the request to be |  | allows the user to indicate that they do not wish the request to be |
| successful if the resource has been changed without their knowledge. |  | successful if the resource has been changed without their knowledge. |
| Examples: |  | Examples: |
| skipping to change at page 11, line 51 |  | skipping to change at page 12, line 37 |
| 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 with a method to |  | The If-Modified-Since request-header field is used with a method to |
| make it conditional: if the requested variant has not been modified |  | make it conditional: if the requested variant has not been modified |
| since the time specified in this field, an entity will not be |  | since the time specified in this field, an entity will not be |
| returned from the server; instead, a 304 (not modified) response will |  | returned from the server; instead, a 304 (Not Modified) response will |
| be returned without any message-body. |  | be returned without any message-body. |
| If-Modified-Since = "If-Modified-Since" ":" HTTP-date |  | If-Modified-Since = "If-Modified-Since" ":" HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| A GET method with an If-Modified-Since header 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 identified entity be transferred only if it has |
| skipping to change at page 14, line 17 |  | skipping to change at page 15, line 4 |
| 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 5 for a discussion of server |  | header MUST be ignored. (See Section 5 for a discussion of server |
| behavior when both If-Modified-Since and If-None-Match appear in the |  | behavior when both If-Modified-Since and If-None-Match appear in the |
| same request.) |  | 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 15.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" |
| If-None-Match: W/"xyzzy" |  | If-None-Match: W/"xyzzy" |
| If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |  | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
| If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |  | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
| skipping to change at page 16, line 12 |  | skipping to change at page 17, line 5 |
| TBD. |  | TBD. |
| 8. Security Considerations |  | 8. Security Considerations |
| No additional security considerations have been identified beyond |  | No additional security considerations have been identified beyond |
| those applicable to HTTP in general [Part1]. |  | those applicable to HTTP in general [Part1]. |
| 9. Acknowledgments |  | 9. Acknowledgments |
| Based on an XML translation of RFC 2616 by Julian Reschke. |  |  |
| 10. References |  | 10. 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 1: URIs, Connections, and Message Parsing", |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| draft-ietf-httpbis-p1-messaging-00 (work in progress), |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-01 |
| December 2007. |  | (work in progress), January 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 5: Range Requests and Partial Responses", |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| draft-ietf-httpbis-p5-range-00 (work in progress), |  | Partial Responses", draft-ietf-httpbis-p5-range-01 (work |
| December 2007. |  | in progress), January 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| progress), December 2007. |  | draft-ietf-httpbis-p6-cache-01 (work in progress), |
|  |  | January 2008. |
|  |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
|  |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
|  |  | 10.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. |
|  |  | Appendix A. Compatibility with Previous Versions |
|  |  | A.1. Changes from RFC 2616 |
|  |  | Appendix B. Change Log (to be removed by RFC Editor before publication) |
|  |  | B.1. Since RFC2616 |
|  |  | Extracted relevant partitions from [RFC2616]. |
|  |  | B.2. Since draft-ietf-httpbis-p4-conditional-00 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |
|  |  | and Informative references" |
|  |  | Other changes: |
|  |  | o Move definitions of 304 and 412 condition codes from Part2. |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 4 |  | 304 Not Modified (status code) 5 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 5 |  | 412 Precondition Failed (status code) 6 |
| E |  | E |
| ETag header 10 |  | ETag header 11 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 4 |  | entity-tag 5 |
| ETag 10 |  | ETag 11 |
| If-Match 10 |  | If-Match 11 |
| If-Modified-Since 12 |  | If-Modified-Since 12 |
| If-None-Match 13 |  | If-None-Match 14 |
| If-Unmodified-Since 14 |  | If-Unmodified-Since 15 |
| Last-Modified 15 |  | Last-Modified 16 |
| opaque-tag 4 |  | opaque-tag 5 |
| weak 4 |  | weak 5 |
| H |  | H |
| Headers |  | Headers |
| ETag 10 |  | ETag 11 |
| If-Match 10 |  | If-Match 11 |
| If-Modified-Since 11 |  | If-Modified-Since 12 |
| If-None-Match 13 |  | If-None-Match 14 |
| If-Unmodified-Since 14 |  | If-Unmodified-Since 15 |
| Last-Modified 15 |  | Last-Modified 16 |
| I |  | I |
| If-Match header 10 |  | If-Match header 11 |
| If-Modified-Since header 11 |  | If-Modified-Since header 12 |
| If-None-Match header 13 |  | If-None-Match header 14 |
| If-Unmodified-Since header 14 |  | If-Unmodified-Since header 15 |
| L |  | L |
| Last-Modified header 15 |  | Last-Modified header 16 |
| S |  | S |
| Status Codes |  | Status Codes |
| 304 Not Modified 4 |  | 304 Not Modified 5 |
| 412 Precondition Failed 5 |  | 412 Precondition Failed 6 |
| 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 |
| skipping to change at page 20, line 4 |  | skipping to change at page 21, line 4 |
| Tim Berners-Lee |  | Tim Berners-Lee |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | Email: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
|  |  | Yves Lafon (editor) |
|  |  | World Wide Web Consortium |
|  |  | W3C / ERCIM |
|  |  | 2004, rte des Lucioles |
|  |  | Sophia-Antipolis, AM 06902 |
|  |  | France |
|  |  | Email: ylafon@w3.org |
|  |  | URI: http://www.raubacapeu.net/people/yves/ |
|  |  | Julian F. Reschke (editor) |
|  |  | greenbytes GmbH |
|  |  | Hafenweg 16 |
|  |  | Muenster, NW 48155 |
|  |  | Germany |
|  |  | Phone: +49 251 2807760 |
|  |  | Fax: +49 251 2807761 |
|  |  | Email: julian.reschke@greenbytes.de |
|  |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  | Full Copyright Statement |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| This document is subject to the rights, licenses and restrictions |  | This document is subject to the rights, licenses and restrictions |
| contained in BCP 78, and except as set forth therein, the authors |  | contained in BCP 78, and except as set forth therein, the authors |
| retain all their rights. |  | retain all their rights. |
| This document and the information contained herein are provided on an |  | This document and the information contained herein are provided on an |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
End of changes. 37 change blocks.
| 93 lines changed or deleted |  | 179 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/