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/ |