Network Working Group M. Nottingham
Internet-Draft Akamai Technologies
Expires: March 23, 2001 September 22, 2000
HTTP Cache Control Extensions for Direct Cache Manipulation
draft-nottingham-cache-extensions-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 23, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
HTTP/1.1 provides for extensions to Cache-Control headers, which
provide new methods of controlling caches. This document specifies
extensions which allow content providers more precise control over
shared caches.
Nottingham Expires March 23, 2001 [Page 1]
Internet-Draft Direct Cache Manipulation Extensions September 2000
1. Introduction
Shared caches are sometimes deployed into the Internet with the
participation of the providers of content which will be flowing
through them. For example, a content provider may use a surrogate
HTTP server to improve performance. Likewise, an access provider who
controls both the origin servers and caching proxies in their
network may wish to optimize the relationship between them.
Although HTTP/1.1 provides mechanisms for controlling caches, it
does not provide an efficient means of controlling objects already
in cache. In the situations outlined above, it would be useful to
allow content providers to manipulate cached objects.
This document provides simple mechanisms to do so, by use of
Cache-Control request header extensions.
It should be noted that because of their nature, the extensions lose
efficiency when used with a large number of shared caches.
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 RFC 2119[2].
An implementation is not compliant if it fails to satisfy one or
more of the MUST or REQUIRED level requirements. An implementation
that satisfies all the MUST or REQUIRED level and all the SHOULD
level requirements is said to be "unconditionally compliant"; one
that satisfies all the MUST level requirements but not all the
SHOULD level requirements is said to be "conditionally compliant".
2. Direct Cache Manipulation Extensions
This section specifies Cache-Control request header extensions which
allow specification of cache operations, as allowed for in
HTTP/1.1[1].
These extensions are intended for the manipulation of shared caches;
they MUST NOT be interpreted by non-shared caches.
Upon receiving one of these extension headers, an implementation
will perform the operation specified, and then MUST return a
response; the type of response returned is dependent on the nature
of the operation.
Such responses MUST NOT have an entity body included. If the status
code returned would normally have a body, a 'Content-Length: 0'
Nottingham Expires March 23, 2001 [Page 2]
Internet-Draft Direct Cache Manipulation Extensions September 2000
header MUST be included.
2.1 Prefetch
The prefetch extension allows content providers to insert an object
into the cache without incurring the expense of a complete round
trip for the object body.
prefetch-extension = "prefetch"
For example, if the resource "http://www.example.com/largeobject"
were requested from a DCM-capable shared cache, with a
"Cache-Control: prefetch" header, the intermediate would operate
exactly as it normally does, except that the response would not
contain an entity body.
This avoids the inefficiency of transporting the object both to the
cache and then to the device which made the request, which is
frequently near the origin server.
Implementations SHOULD support validation, server-driven content
negotiation and other HTTP mechanisms in conjunction with this
mechanism.
The prefetch extension MUST NOT be forwarded by implementations.
2.2 Eject
This extension enables the eviction of objects from the cache. When
an implementation receives this directive, it MUST evict the object
identified by the resource, so that the next request for the
resource is unconditional (unless the request itself is conditional).
eject-extension = "eject"
When ejecting objects, implementations MUST eject all variants of
the resource identified.
Requests containing the eject extension MUST NOT be forwarded by
implementations.
3. Security Considerations
This document does not address security-related issues, but the
mechanisms it describes should be used in conjuction with
appropriate authentication and authorization control. Such control
may be implementation-specific, although there are defined
mechanisms in the HTTP and elsewhere that may be appropriate.
Nottingham Expires March 23, 2001 [Page 3]
Internet-Draft Direct Cache Manipulation Extensions September 2000
In particular, unauthorized use of these mechanisms may lead to
reduced cache efficiency, denial of service to the intermediate, and
may make other security issues in the intermediate more readily
exploitable.
References
[1] Fielding, R., Gettys, J., Mogul, J. C., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol
- HTTP/1.1", RFC 2616, June 1999.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Author's Address
Mark Nottingham
Akamai Technologies
Suite 703, 1400 Fashion Island Bvld
San Mateo, CA 94404
US
EMail: mnot@akamai.com
URI: http://www.mnot.net/
Nottingham Expires March 23, 2001 [Page 4]
Internet-Draft Direct Cache Manipulation Extensions September 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Nottingham Expires March 23, 2001 [Page 5]