draft-ietf-httpbis-p6-cache-06.txt   draft-ietf-httpbis-p6-cache-07.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: September 10, 2009 J. Mogul Expires: January 14, 2010 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
M. Nottingham, Ed.
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 9, 2009 July 13, 2009
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-06 draft-ietf-httpbis-p6-cache-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 4 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 41 skipping to change at page 2, line 44
or indicate cacheable response messages. or indicate cacheable response messages.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://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://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.7. The changes in this draft are summarized in Appendix C.8.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. ABNF Rules defined in other Parts of the 1.4.2. ABNF Rules defined in other Parts of the
skipping to change at page 3, line 27 skipping to change at page 3, line 27
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
2.2. Constructing Responses from Caches . . . . . . . . . . . . 8 2.2. Constructing Responses from Caches . . . . . . . . . . . . 8
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14
2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15
2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18
3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 4, line 9 skipping to change at page 4, line 9
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 33 publication) . . . . . . . . . . . . . . . . . . . . 33
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
HTTP is typically used for distributed information systems, where HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches. This performance can be improved by the use of response caches. This
document defines aspects of HTTP/1.1 related to caching and reusing document defines aspects of HTTP/1.1 related to caching and reusing
response messages. response messages.
1.1. Purpose 1.1. Purpose
skipping to change at page 7, line 39 skipping to change at page 7, line 39
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
1.4.2. ABNF Rules defined in other Parts of the Specification 1.4.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
field-name = <field-name, defined in [Part1], Section 4.2> field-name = <field-name, defined in [Part1], Section 4.2>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
port = <port, defined in [Part1], Section 2.1> port = <port, defined in [Part1], Section 2.1>
pseudonym = <pseudonym, defined in [Part1], Section 8.9> pseudonym = <pseudonym, defined in [Part1], Section 8.9>
uri-host = <uri-host, defined in [Part1], Section 2.1> uri-host = <uri-host, defined in [Part1], Section 2.1>
2. Cache Operation 2. Cache Operation
2.1. Response Cacheability 2.1. Response Cacheability
A cache MUST NOT store a response to any request, unless: A cache MUST NOT store a response to any request, unless:
skipping to change at page 8, line 45 skipping to change at page 8, line 45
A cache that does not support the Range and Content-Range headers A cache that does not support the Range and Content-Range headers
MUST NOT store incomplete or partial responses. MUST NOT store incomplete or partial responses.
2.2. Constructing Responses from Caches 2.2. Constructing Responses from Caches
For a presented request, a cache MUST NOT return a stored response, For a presented request, a cache MUST NOT return a stored response,
unless: unless:
o The presented Request-URI and that of the stored response match o The presented Request-URI and that of the stored response match
(see [[anchor1: TBD]]), and ([[TODO-Request-URI: Need to find a new term for this, as Part 1
doesn't define Request-URI anymore; the new term request-target
does not work for this.]]), and
o the request method associated with the stored response allows it o the request method associated with the stored response allows it
to be used for the presented request, and to be used for the presented request, and
o selecting request-headers nominated by the stored response (if o selecting request-headers nominated by the stored response (if
any) match those presented (see Section 2.6), and any) match those presented (see Section 2.6), and
o the presented request and stored response are free from directives o the presented request and stored response are free from directives
that would prevent its use (see Section 3.2 and Section 3.4), and that would prevent its use (see Section 3.2 and Section 3.4), and
o the stored response is either: o the stored response is either:
* fresh (see Section 2.3), or * fresh (see Section 2.3), or
* allowed to be served stale (see Section 2.3.3), or * allowed to be served stale (see Section 2.3.3), or
* successfully validated (see Section 2.4). * successfully validated (see Section 2.4).
skipping to change at page 9, line 15 skipping to change at page 9, line 18
that would prevent its use (see Section 3.2 and Section 3.4), and that would prevent its use (see Section 3.2 and Section 3.4), and
o the stored response is either: o the stored response is either:
* fresh (see Section 2.3), or * fresh (see Section 2.3), or
* allowed to be served stale (see Section 2.3.3), or * allowed to be served stale (see Section 2.3.3), or
* successfully validated (see Section 2.4). * successfully validated (see Section 2.4).
[[anchor2: TODO: define method cacheability for GET, HEAD and POST in [[TODO-method-cacheability: define method cacheability for GET, HEAD
p2-semantics.]] and POST in p2-semantics.]]
When a stored response is used to satisfy a request, caches MUST When a stored response is used to satisfy a request, caches MUST
include a single Age header field Section 3.1 in the response with a include a single Age header field (Section 3.1) in the response with
value equal to the stored response's current_age; see Section 2.3.2. a value equal to the stored response's current_age; see
[[anchor3: DISCUSS: this currently includes successfully validated Section 2.3.2. [[anchor1: DISCUSS: this currently includes
responses.]] successfully validated responses.]]
Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST
be written through the cache to the origin server; i.e., A cache must be written through the cache to the origin server; i.e., A cache must
not reply to such a request before having forwarded the request and not reply to such a request before having forwarded the request and
having received a corresponding response. having received a corresponding response.
Also, note that unsafe requests might invalidate already stored Also, note that unsafe requests might invalidate already stored
responses; see Section 2.5. responses; see Section 2.5.
Caches MUST use the most recent response (as determined by the Date Caches MUST use the most recent response (as determined by the Date
header) when more than one suitable response is stored. They can header) when more than one suitable response is stored. They can
also forward a request with "Cache-Control: max-age=0" or "Cache- also forward a request with "Cache-Control: max-age=0" or "Cache-
Control: no-cache" to disambiguate which response to use. Control: no-cache" to disambiguate which response to use.
[[anchor4: TODO: end-to-end and hop-by-hop headers, non-modifiable [[TODO-header-properties: end-to-end and hop-by-hop headers, non-
headers removed; re-spec in p1]] modifiable headers removed; re-spec in p1]]
2.3. Freshness Model 2.3. Freshness Model
When a response is "fresh" in the cache, it can be used to satisfy When a response is "fresh" in the cache, it can be used to satisfy
subsequent requests without contacting the origin server, thereby subsequent requests without contacting the origin server, thereby
improving efficiency. improving efficiency.
The primary mechanism for determining freshness is for an origin The primary mechanism for determining freshness is for an origin
server to provide an explicit expiration time in the future, using server to provide an explicit expiration time in the future, using
either the Expires header (Section 3.3) or the max-age response cache either the Expires header (Section 3.3) or the max-age response cache
directive (Section 3.2.2). Generally, origin servers will assign directive (Section 3.2.2). Generally, origin servers will assign
future explicit expiration times to responses in the belief that the future explicit expiration times to responses in the belief that the
entity is not likely to change in a semantically significant way entity is not likely to change in a semantically significant way
before the expiration time is reached. before the expiration time is reached.
If an origin server wishes to force a cache to validate every If an origin server wishes to force a cache to validate every
request, it can assign an explicit expiration time in the past. This request, it can assign an explicit expiration time in the past. This
means that the response is always stale, so that caches should means that the response is always stale, so that caches should
validate it before using it for subsequent requests. [[anchor5: This validate it before using it for subsequent requests. [[anchor2: This
wording may cause confusion, because the response may still be served wording may cause confusion, because the response may still be served
stale.]] stale.]]
Since origin servers do not always provide explicit expiration times, Since origin servers do not always provide explicit expiration times,
HTTP caches may also assign heuristic expiration times when they are HTTP caches may also assign heuristic expiration times when they are
not specified, employing algorithms that use other header values not specified, employing algorithms that use other header values
(such as the Last-Modified time) to estimate a plausible expiration (such as the Last-Modified time) to estimate a plausible expiration
time. The HTTP/1.1 specification does not provide specific time. The HTTP/1.1 specification does not provide specific
algorithms, but does impose worst-case constraints on their results. algorithms, but does impose worst-case constraints on their results.
skipping to change at page 10, line 32 skipping to change at page 10, line 35
response_is_fresh = (freshness_lifetime > current_age) response_is_fresh = (freshness_lifetime > current_age)
The freshness_lifetime is defined in Section 2.3.1; the current_age The freshness_lifetime is defined in Section 2.3.1; the current_age
is defined in Section 2.3.2. is defined in Section 2.3.2.
Additionally, clients may need to influence freshness calculation. Additionally, clients may need to influence freshness calculation.
They can do this using several request cache directives, with the They can do this using several request cache directives, with the
effect of either increasing or loosening constraints on freshness. effect of either increasing or loosening constraints on freshness.
See Section 3.2.1. See Section 3.2.1.
[[anchor6: ISSUE: there are not requirements directly applying to [[anchor3: ISSUE: there are not requirements directly applying to
cache-request-directives and freshness.]] cache-request-directives and freshness.]]
Note that freshness applies only to cache operation; it cannot be Note that freshness applies only to cache operation; it cannot be
used to force a user agent to refresh its display or reload a used to force a user agent to refresh its display or reload a
resource. See Section 4 for an explanation of the difference between resource. See Section 4 for an explanation of the difference between
caches and history mechanisms. caches and history mechanisms.
2.3.1. Calculating Freshness Lifetime 2.3.1. Calculating Freshness Lifetime
A cache can calculate the freshness lifetime (denoted as A cache can calculate the freshness lifetime (denoted as
skipping to change at page 11, line 30 skipping to change at page 11, line 33
When a heuristic is used to calculate freshness lifetime, the cache When a heuristic is used to calculate freshness lifetime, the cache
SHOULD attach a Warning header with a 113 warn-code to the response SHOULD attach a Warning header with a 113 warn-code to the response
if its current_age is more than 24 hours and such a warning is not if its current_age is more than 24 hours and such a warning is not
already present. already present.
Also, if the response has a Last-Modified header (Section 6.6 of Also, if the response has a Last-Modified header (Section 6.6 of
[Part4]), the heuristic expiration value SHOULD be no more than some [Part4]), the heuristic expiration value SHOULD be no more than some
fraction of the interval since that time. A typical setting of this fraction of the interval since that time. A typical setting of this
fraction might be 10%. fraction might be 10%.
[[anchor7: REVIEW: took away HTTP/1.0 query string heuristic [[anchor4: REVIEW: took away HTTP/1.0 query string heuristic
uncacheability.]] uncacheability.]]
2.3.2. Calculating Age 2.3.2. Calculating Age
HTTP/1.1 uses the Age response-header to convey the estimated age of HTTP/1.1 uses the Age response-header to convey the estimated age of
the response message when obtained from a cache. The Age field value the response message when obtained from a cache. The Age field value
is the cache's estimate of the amount of time since the response was is the cache's estimate of the amount of time since the response was
generated or validated by the origin server. In essence, the Age generated or validated by the origin server. In essence, the Age
value is the sum of the time that the response has been resident in value is the sum of the time that the response has been resident in
each of the caches along the path from the origin server, plus the each of the caches along the path from the origin server, plus the
skipping to change at page 13, line 36 skipping to change at page 13, line 50
If a cache receives a first-hand response (either an entire response, If a cache receives a first-hand response (either an entire response,
or a 304 (Not Modified) response) that it would normally forward to or a 304 (Not Modified) response) that it would normally forward to
the requesting client, and the received response is no longer fresh, the requesting client, and the received response is no longer fresh,
the cache SHOULD forward it to the requesting client without adding a the cache SHOULD forward it to the requesting client without adding a
new Warning (but without removing any existing Warning headers). A new Warning (but without removing any existing Warning headers). A
cache SHOULD NOT attempt to validate a response simply because that cache SHOULD NOT attempt to validate a response simply because that
response became stale in transit. response became stale in transit.
2.4. Validation Model 2.4. Validation Model
Checking with the origin server to see if a stale or otherwise When a cache has one or more stored responses for a requested URI,
unusable cached response can be reused is called "validating" or but cannot serve any of them (e.g., because they are not fresh, or
"revalidating." Doing so potentially avoids the overhead of one cannot be selected; see Section 2.6), it can use the conditional
retransmitting the response body when the stored response is valid. request mechanism [Part4] in the forwarded request to give the origin
server an opportunity to both select a valid stored response to be
used, and to update it. This process is known as "validating" or
"revalidating" the stored response.
HTTP's conditional request mechanism [Part4] is used for this When sending such a conditional request, the cache SHOULD add an If-
purpose. When a stored response includes one or more validators, Modified-Since header whose value is that of the Last-Modified header
such as the field values of an ETag or Last-Modified header field, from the selected (see Section 2.6) stored response, if available.
then a validating request SHOULD be made conditional to those field
values. Additionally, the cache SHOULD add an If-None-Match header whose
value is that of the ETag header(s) from all responses stored for the
requested URI, if present. However, if any of the stored responses
contains only partial content, its entity-tag SHOULD NOT be included
in the If-None-Match header field unless the request is for a range
that would be fully satisfied by that stored response.
A 304 (Not Modified) response status code indicates that the stored A 304 (Not Modified) response status code indicates that the stored
response can be updated and reused; see Section 2.7. response can be updated and reused; see Section 2.7.
If instead the cache receives a full response (i.e., one with a A full response (i.e., one with a response body) indicates that none
response body), it is used to satisfy the request and replace the of the stored responses nominated in the conditional request is
stored response. [[anchor8: Should there be a requirement here?]] suitable. Instead, the full response is used both to satisfy the
request and replace the stored response. [[anchor5: Should there be a
requirement here?]]
If a cache receives a 5xx response while attempting to validate a If a cache receives a 5xx response while attempting to validate a
response, it MAY either forward this response to the requesting response, it MAY either forward this response to the requesting
client, or act as if the server failed to respond. In the latter client, or act as if the server failed to respond. In the latter
case, it MAY return a previously stored response (which SHOULD case, it MAY return a previously stored response (see Section 2.3.3).
include the 111 warn-code; see Section 3.6) unless the stored
response includes the "must-revalidate" cache directive (see If a cache receives a successful response whose Content-Location
Section 2.3.3). field matches that of an existing stored response for the same
Request-URI, whose entity-tag differs from that of the existing
stored response, and whose Date is more recent than that of the
existing response, the existing response SHOULD NOT be returned in
response to future requests and SHOULD be deleted from the cache.
[[anchor6: DISCUSS: Not sure if this is necessary.]]
2.5. Request Methods that Invalidate 2.5. Request Methods that Invalidate
Because unsafe methods (Section 7.1.1 of [Part2]) have the potential Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
for changing state on the origin server, intervening caches can use for changing state on the origin server, intervening caches can use
them to keep their contents up-to-date. them to keep their contents up-to-date.
The following HTTP methods MUST cause a cache to invalidate the The following HTTP methods MUST cause a cache to invalidate the
Request-URI as well as the Location and Content-Location headers (if Request-URI as well as the URI(s) in the Location and Content-
present): Location headers (if present):
o PUT o PUT
o DELETE o DELETE
o POST o POST
An invalidation based on the URI in a Location or Content-Location An invalidation based on a URI from a Location or Content-Location
header MUST NOT be performed if the host part of that URI differs header MUST NOT be performed if the host part of that URI differs
from the host part in the Request-URI. This helps prevent denial of from the host part in the Request-URI. This helps prevent denial of
service attacks. service attacks.
[[anchor9: TODO: "host part" needs to be specified better.]] [[anchor7: TODO: "host part" needs to be specified better.]]
A cache that passes through requests for methods it does not A cache that passes through requests for methods it does not
understand SHOULD invalidate the Request-URI. understand SHOULD invalidate the Request-URI.
Here, "invalidate" means that the cache will either remove all stored Here, "invalidate" means that the cache will either remove all stored
responses related to the Request-URI, or will mark these as "invalid" responses related to the Request-URI, or will mark these as "invalid"
and in need of a mandatory validation before they can be returned in and in need of a mandatory validation before they can be returned in
response to a subsequent request. response to a subsequent request.
Note that this does not guarantee that all appropriate responses are Note that this does not guarantee that all appropriate responses are
invalidated. For example, the request that caused the change at the invalidated. For example, the request that caused the change at the
origin server might not have gone through the cache where a response origin server might not have gone through the cache where a response
is stored. is stored.
[[anchor10: TODO: specify that only successful (2xx, 3xx?) responses [[anchor8: TODO: specify that only successful (2xx, 3xx?) responses
invalidate.]] invalidate.]]
2.6. Caching Negotiated Responses 2.6. Caching Negotiated Responses
Use of server-driven content negotiation (Section 4.1 of [Part3])
alters the conditions under which a cache can use the response for
subsequent requests.
When a cache receives a request that can be satisfied by a stored When a cache receives a request that can be satisfied by a stored
response that includes a Vary header field (Section 3.5), it MUST NOT response that has a Vary header field (Section 3.5), it MUST NOT use
use that response unless all of the selecting request-headers in the that response unless all of the selecting request-headers nominated
presented request match the corresponding stored request-headers from by the Vary header match in both the original request (i.e., that
the original request. associated with the stored response), and the presented request.
The selecting request-headers from two requests are defined to match The selecting request-headers from two requests are defined to match
if and only if the selecting request-headers in the first request can if and only if the selecting request-headers in the first request can
be transformed to the selecting request-headers in the second request be transformed to the selecting request-headers in the second request
by adding or removing linear white space [[anchor11: [ref]]] at by adding or removing linear white space [[anchor9: [ref]]] at places
places where this is allowed by the corresponding ABNF, and/or where this is allowed by the corresponding ABNF, and/or combining
combining multiple message-header fields with the same field name multiple message-header fields with the same field name following the
following the rules about message headers in Section 4.2 of [Part1]. rules about message headers in Section 4.2 of [Part1].
[[anchor12: DISCUSS: header-specific canonicalisation]]
If a header field is absent from a request, it can only match another
request if it is also absent there.
A Vary header field-value of "*" always fails to match, and A Vary header field-value of "*" always fails to match, and
subsequent requests to that resource can only be properly interpreted subsequent requests to that resource can only be properly interpreted
by the origin server. by the origin server.
If no stored response matches, the cache MAY forward the presented The stored response with matching selecting request-headers is known
request to the origin server in a conditional request, and SHOULD as the selected response.
include all ETags stored with potentially suitable responses in an
If-None-Match request header. If the server responds with 304 (Not
Modified) and includes an entity tag or Content-Location that
indicates the entity to be used, that cached response MUST be used to
satisfy the presented request, and SHOULD be used to update the
corresponding stored response; see Section 2.7.
If any of the stored responses contains only partial content, its
entity-tag SHOULD NOT be included in the If-None-Match header field
unless the request is for a range that would be fully satisfied by
that stored response.
If a cache receives a successful response whose Content-Location If no selected response is available, the cache MAY forward the
field matches that of an existing stored response for the same presented request to the origin server in a conditional request; see
Request-URI, whose entity-tag differs from that of the existing Section 2.4.
stored response, and whose Date is more recent than that of the
existing response, the existing response SHOULD NOT be returned in
response to future requests and SHOULD be deleted from the
cache.[[anchor13: DISCUSS: Not sure if this is necessary.]]
2.7. Combining Responses 2.7. Combining Responses
When a cache receives a 304 (Not Modified) response or a 206 (Partial When a cache receives a 304 (Not Modified) response or a 206 (Partial
Content) response, it needs to update the stored response with the Content) response (in this section, the "new" response"), it needs to
new one, so that the updated response can be sent to the client. created an updated response by combining the stored response with the
new one, so that the updated response can be used to satisfy the
request.
If the status code is 304 (Not Modified), the cache SHOULD use the If the new response contains an ETag, it identifies the stored
stored entity-body as the updated entity-body. If the status code is response to use. [[anchor10: may need language about Content-Location
206 (Partial Content) and the ETag or Last-Modified headers match here]][[anchor11: cover case where INM with multiple etags was sent]]
exactly, the cache MAY combine the stored entity-body in the stored
response with the updated entity-body received in the response and
use the result as the updated entity-body (see Section 4 of [Part5]).
The stored response headers are used for the updated response, except If the status code is 206 (partial content), both the stored and new
that responses MUST have ETags, and those ETags MUST match using the
strong comparison function (see Section 4 of [Part4]). Otherwise,
the responses MUST NOT be combined.
The stored response headers are used as those of the updated
response, except that
o any stored Warning headers with warn-code 1xx (see Section 3.6) o any stored Warning headers with warn-code 1xx (see Section 3.6)
MUST be deleted from the stored response and the forwarded MUST be deleted from the stored response and the updated response.
response.
o any stored Warning headers with warn-code 2xx MUST be retained in o any stored Warning headers with warn-code 2xx MUST be retained in
the stored response and the forwarded response. the stored response and the updated response.
o any headers provided in the 304 or 206 response MUST replace the o any headers provided in the new response MUST replace the
corresponding headers from the stored response. corresponding headers from the stored response.
A cache MUST also replace any stored headers with corresponding If a header field-name in the new response matches more than one
headers received in the incoming response, except for Warning headers header in the stored response, all such stored headers MUST be
as described immediately above. If a header field-name in the replaced.
incoming response matches more than one header in the stored
response, all such old headers MUST be replaced. It MAY store the
combined entity-body.
[[anchor14: ISSUE: discuss how to handle HEAD updates]] The updated response can [[[[anchor12: requirement?]]]] be used to
replace the stored response in cache. In the case of a 206 response,
the combined entity-body MAY be stored.
[[anchor13: ISSUE: discuss how to handle HEAD updates]]
3. Header Field Definitions 3. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to caching. fields related to caching.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
3.1. Age 3.1. Age
The response-header field "Age" conveys the sender's estimate of the The response-header field "Age" conveys the sender's estimate of the
amount of time since the response (or its validation) was generated amount of time since the response (or its validation) was generated
at the origin server. Age values are calculated as specified in at the origin server. Age values are calculated as specified in
Section 2.3.2. Section 2.3.2.
Age = "Age" ":" OWS Age-v Age = "Age" ":" OWS Age-v
Age-v = delta-seconds Age-v = delta-seconds
Age field-values are non-negative decimal integers, representing time Age field-values are non-negative integers, representing time in
in seconds. seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
If a cache receives a value larger than the largest positive integer If a cache receives a value larger than the largest positive integer
it can represent, or if any of its age calculations overflows, it it can represent, or if any of its age calculations overflows, it
MUST transmit an Age header with a field-value of 2147483648 (2^31). MUST transmit an Age header with a field-value of 2147483648 (2^31).
Caches SHOULD use an arithmetic type of at least 31 bits of range. Caches SHOULD use an arithmetic type of at least 31 bits of range.
The presence of an Age header field in a response implies that a The presence of an Age header field in a response implies that a
response is not first-hand. However, the converse is not true, since response is not first-hand. However, the converse is not true, since
skipping to change at page 19, line 13 skipping to change at page 19, line 21
client is not willing to accept a stale response. client is not willing to accept a stale response.
max-stale max-stale
The max-stale request directive indicates that the client is The max-stale request directive indicates that the client is
willing to accept a response that has exceeded its expiration willing to accept a response that has exceeded its expiration
time. If max-stale is assigned a value, then the client is time. If max-stale is assigned a value, then the client is
willing to accept a response that has exceeded its expiration time willing to accept a response that has exceeded its expiration time
by no more than the specified number of seconds. If no value is by no more than the specified number of seconds. If no value is
assigned to max-stale, then the client is willing to accept a assigned to max-stale, then the client is willing to accept a
stale response of any age. [[anchor15: of any staleness? --mnot]] stale response of any age. [[anchor14: of any staleness? --mnot]]
min-fresh min-fresh
The min-fresh request directive indicates that the client is The min-fresh request directive indicates that the client is
willing to accept a response whose freshness lifetime is no less willing to accept a response whose freshness lifetime is no less
than its current age plus the specified time in seconds. That is, than its current age plus the specified time in seconds. That is,
the client wants a response that will still be fresh for at least the client wants a response that will still be fresh for at least
the specified number of seconds. the specified number of seconds.
no-transform no-transform
skipping to change at page 20, line 51 skipping to change at page 20, line 51
no-cache no-cache
The no-cache response directive indicates that the response MUST The no-cache response directive indicates that the response MUST
NOT be used to satisfy a subsequent request without successful NOT be used to satisfy a subsequent request without successful
validation on the origin server. This allows an origin server to validation on the origin server. This allows an origin server to
prevent caching even by caches that have been configured to return prevent caching even by caches that have been configured to return
stale responses. stale responses.
If the no-cache response directive specifies one or more field- If the no-cache response directive specifies one or more field-
names, this requirement is limited to the field-values assosicated names, this requirement is limited to the field-values associated
with the listed response headers. That is, the specified field- with the listed response headers. That is, the specified field-
name(s) MUST NOT be sent in the response to a subsequent request name(s) MUST NOT be sent in the response to a subsequent request
without successful validation on the origin server. This allows without successful validation on the origin server. This allows
an origin server to prevent the re-use of certain header fields in an origin server to prevent the re-use of certain header fields in
a response, while still allowing caching of the rest of the a response, while still allowing caching of the rest of the
response. response.
Note: Most HTTP/1.0 caches will not recognize or obey this Note: Most HTTP/1.0 caches will not recognize or obey this
directive. directive.
skipping to change at page 23, line 26 skipping to change at page 23, line 26
The entity-header field "Expires" gives the date/time after which the The entity-header field "Expires" gives the date/time after which the
response is considered stale. See Section 2.3 for further discussion response is considered stale. See Section 2.3 for further discussion
of the freshness model. of the freshness model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The field-value is an absolute date and time as defined by HTTP-date The field-value is an absolute date and time as defined by HTTP-date
in Section 3.2.1 of [Part1]; it MUST be sent in rfc1123-date format. in Section 3.2 of [Part1]; it MUST be sent in rfc1123-date format.
Expires = "Expires" ":" OWS Expires-v Expires = "Expires" ":" OWS Expires-v
Expires-v = HTTP-date Expires-v = HTTP-date
For example For example
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: if a response includes a Cache-Control field with the max- Note: if a response includes a Cache-Control field with the max-
age directive (see Section 3.2.2), that directive overrides the age directive (see Section 3.2.2), that directive overrides the
skipping to change at page 29, line 48 skipping to change at page 29, line 48
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-06 and Message Parsing", draft-ietf-httpbis-p1-messaging-07
(work in progress), March 2009. (work in progress), July 2009.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-06 (work in Semantics", draft-ietf-httpbis-p2-semantics-07 (work in
progress), March 2009. progress), July 2009.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-06 and Content Negotiation", draft-ietf-httpbis-p3-payload-07
(work in progress), March 2009. (work in progress), July 2009.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-06 (work in Requests", draft-ietf-httpbis-p4-conditional-07 (work in
progress), March 2009. progress), July 2009.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-06 (work Partial Responses", draft-ietf-httpbis-p5-range-07 (work
in progress), March 2009. in progress), July 2009.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
draft-ietf-httpbis-p7-auth-06 (work in progress), draft-ietf-httpbis-p7-auth-07 (work in progress),
March 2009. July 2009.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 31, line 20 skipping to change at page 31, line 20
A.1. Changes from RFC 2068 A.1. Changes from RFC 2068
A case was missed in the Cache-Control model of HTTP/1.1; s-maxage A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
was introduced to add this missing case. (Sections 2.1, 3.2). was introduced to add this missing case. (Sections 2.1, 3.2).
Transfer-coding and message lengths all interact in ways that Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important transfer encoding that may not be self delimiting); it was important
to straighten out exactly how message lengths are computed. (see also to straighten out exactly how message lengths are computed. (see also
[Part1], [Part3] and [Part5]) [[anchor18: This used to refer to the [Part1], [Part3] and [Part5]) [[anchor17: This used to refer to the
text about non-modifiable headers, and will have to be updated later text about non-modifiable headers, and will have to be updated later
on. --jre]] on. --jre]]
Proxies should be able to add Content-Length when appropriate. Proxies should be able to add Content-Length when appropriate.
[[anchor19: This used to refer to the text about non-modifiable [[anchor18: This used to refer to the text about non-modifiable
headers, and will have to be updated later on. --jre]] headers, and will have to be updated later on. --jre]]
Range request responses would become very verbose if all meta-data Range request responses would become very verbose if all meta-data
were always returned; by allowing the server to only send needed were always returned; by allowing the server to only send needed
headers in a 206 response, this problem can be avoided. headers in a 206 response, this problem can be avoided.
(Section 2.7) (Section 2.7)
The Cache-Control: max-age directive was not properly defined for The Cache-Control: max-age directive was not properly defined for
responses. (Section 3.2.2) responses. (Section 3.2.2)
skipping to change at page 32, line 10 skipping to change at page 32, line 10
Age = "Age:" OWS Age-v Age = "Age:" OWS Age-v
Age-v = delta-seconds Age-v = delta-seconds
Cache-Control = "Cache-Control:" OWS Cache-Control-v Cache-Control = "Cache-Control:" OWS Cache-Control-v
Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] ) cache-directive ] )
Expires = "Expires:" OWS Expires-v Expires = "Expires:" OWS Expires-v
Expires-v = HTTP-date Expires-v = HTTP-date
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Pragma = "Pragma:" OWS Pragma-v Pragma = "Pragma:" OWS Pragma-v
Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] ) pragma-directive ] )
Vary = "Vary:" OWS Vary-v Vary = "Vary:" OWS Vary-v
Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name
] ) ) ] ) )
skipping to change at page 35, line 42 skipping to change at page 35, line 42
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods
and Caching" and Caching"
In addition: Final work on ABNF conversion In addition: Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Add appendix containing collected and expanded ABNF, reorganize o Add appendix containing collected and expanded ABNF, reorganize
ABNF introduction. ABNF introduction.
C.8. Since draft-ietf-httpbis-p6-cache-06
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements"
Affected issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non-
existant headers
Index Index
A A
age 6 age 6
Age header 17 Age header 17
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 18, 21 max-age 19, 21
max-stale 19 max-stale 19
min-fresh 19 min-fresh 19
must-revalidate 21 must-revalidate 21
no-cache 18, 20 no-cache 18, 20
no-store 18, 21 no-store 18, 21
no-transform 19, 22 no-transform 19, 22
only-if-cached 19 only-if-cached 19
private 20 private 20
proxy-revalidate 21 proxy-revalidate 21
public 20 public 20
skipping to change at page 37, line 16 skipping to change at page 37, line 27
Age 17 Age 17
Cache-Control 17 Cache-Control 17
Expires 23 Expires 23
Pragma 23 Pragma 23
Vary 24 Vary 24
Warning 25 Warning 25
heuristic expiration time 5 heuristic expiration time 5
M M
max-age max-age
Cache Directive 18, 21 Cache Directive 19, 21
max-stale max-stale
Cache Directive 19 Cache Directive 19
min-fresh min-fresh
Cache Directive 19 Cache Directive 19
must-revalidate must-revalidate
Cache Directive 21 Cache Directive 21
N N
no-cache no-cache
Cache Directive 18, 20 Cache Directive 18, 20
skipping to change at page 39, line 30 skipping to change at page 40, 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) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
Email: ylafon@w3.org Email: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Mark Nottingham (editor)
Email: mnot@mnot.net
URI: http://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 58 change blocks. 
119 lines changed or deleted 145 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/