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/