[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]