Network Working Group I. Cooper
Internet-Draft Mirror Image
Expires: December 30, 1999 July 1999
Inter Cache Co-operation, Protocol Extensions
draft-cooper-intercache-cooper-00.txt
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 December 30, 1999.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This memo is aimed at implementors of caching proxies using
HTTP/1.1[1] and ICPv2[2]. It describes small extensions to these
protocols which are intended to aid the inter-operation of caching
proxies. These extensions provide debug facilities, optimizations
for ICP reply messages, and the ability to request object purge
operations.
Cooper Expires December 30, 1999 [Page 1]
Internet-Draft Inter Cache Extensions July 1999
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Object Tracing . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Object Purge . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Trivial Purge . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Decisive Purge . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Valid HTTP response codes for PURGE . . . . . . . . . . . . 7
4. Removal of URL from ICP replies . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . 10
5.1 Via header . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Trivial purges . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Decisive purges . . . . . . . . . . . . . . . . . . . . . . 10
5.4 Removal of URL from ICP replies . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
A. Inter-Cache Mailing List . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
Cooper Expires December 30, 1999 [Page 2]
Internet-Draft Inter Cache Extensions July 1999
1. Introduction
The extensions outlined in this memo are intended to address a small
number of issues that currently limit the inter-operation of caching
proxies. Rather than attempt to develop new protocols at this time,
the document defines extensions to both HTTP/1.1[1] and ICPv2[2]:
o additional debug information in the comments field of HTTP Via
headers to allow object tracing
o inter-cache purge messages (within ICP and HTTP)
o optimization of ICP reply messages
These modifications have been agreed upon by a group of cache
vendors, and other individuals, participating on the Inter-Cache
mailing list (informally known as the "Inter-Cache Group"). Comments
about this document should be sent to the document editor, or to the
Inter-Cache Group mailing list. Details on how to subscribe to this
list can be found in Appendix A.
Cooper Expires December 30, 1999 [Page 3]
Internet-Draft Inter Cache Extensions July 1999
2. Object Tracing
While RFC2616 requires the addition, or modification, of a Via
header, the syntax does not provide sufficient information to enable
cache administrators to identify possible cache validation problems.
To aid this task, this document defines the semantics for the
comment field within the existing Via header structure below.
The following is the definition of the Via header, taken from
RFC2616, Section 14.45:
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
Since "comment" contains pre-defined syntax within RFC2616, we must
redefine Via for the purposes of this document. This redefinition is
only for the convenience of providing BNF within this document.
Via = "Via" ":" 1#( received-protocol received-by
[ (comment | ic-comment) ] )
ic-comment = "(" product-name "/" product-version [ tracecode
[ trace-time ] ] ")"
product-name = token
product-version = token
tracecode = "UNVERIFIED_CACHE_HIT"
| "VERIFIED_CACHE_HIT"
| "CACHE_MISS"
trace-time = HTTP-Date ; see RFC2616
There are security considerations in the provision of product
information and the location of particular proxies. RFC2616
recommends that a pseudonym be used where the information in a Via
string is sensitive. Trivial pseudonyms are likely to be useless
for cache administration, and were therefore recommend that
sufficient human-readable information is provided.
Trace codes are included to aid cache administrators in determining
whether a cached copy of the content was passed, and if so whether
this was validated for the transaction. These codes are included
solely for the purposes of debugging. They MUST NOT be used to
infer any consistency quality preferences between verified and
unverified cache hits.
Trace codes explained:
Cooper Expires December 30, 1999 [Page 4]
Internet-Draft Inter Cache Extensions July 1999
CACHE_MISS
The entity supplied was not found in the cache's store. This is a
copy provided by either the origin server or the cache's parent.
UNVERIFIED_CACHE_HIT
The entity supplied was taken from the cache's store, and was not
verified with the origin server, or parent, before being served.
Any cache which does not perform real-time validation as the
result of a client request MUST use the UNVERIFIED_CACHE_HIT
tracecode in the event of a cached object being served.
The optional trace-time MAY be used to indicate the last time
that the cached content was validated.
VERIFIED_CACHE_HIT
The entity supplied was taken from the cache's store and was
validated to determine that it was fresh.
2.1 Example
The following example shows a sample Via header with extensions in
the comment field. The comment indicates that version 4.1 of the
"MIIxpc" product served the content without verifying in real-time,
and that the last validation took place at 16:07:27 GMT on Monday 9
August 1999.
HTTP/1.1 200 OK
Connection: close
Server: Apache/1.2.6 Red Hat
Last-Modified: Mon, 09 Aug 1999 15:35:25 GMT
Content-Type: image/gif
Via: 1.1 site.xpc-mii.net (MIIxpc/4.1 UNVERIFIED_CACHE_HIT Mon, 09 Aug 1999 16:07:27 GMT)
.
.
.
Note: Implementors are cautioned to examine the support of
continuation header lines within their products.
Cooper Expires December 30, 1999 [Page 5]
Internet-Draft Inter Cache Extensions July 1999
3. Object Purge
Inter-cache object purge messages are proposed to enable
co-operating caches to aid each other with the task of ensuring
object consistency. Two methods of purge request propagation are
proposed below:
o Trivial (small overhead, no guarantee of delivery, unknown
outcome)
o Decisive (higher overhead, guarantee of delivery, known outcome)
Trivial requests are lightweight, using an extension to ICPv2 for
transmission. A response from the receiving cache is NOT given.
Decisive requests require responses to indicate the success or
otherwise of the purge request, even if such a response indicates
that the server will not purge the content.
The purge model is intended for closed administrative domains, or
where there is a known relationship between co-operating caches.
Caches SHOULD NOT forward purge requests unless configured to do so.
Where configured to do so, purge requests SHOULD be propagated to
the children, siblings, and parents of the receiving cache on a best
effort basis unless otherwise indicated by the inclusion of a
Max-Forwards header in a Decisive purge. Purge requests are
intended only for cache control and MUST NOT be propagated to origin
servers.
In all cases a purge request is applicable ONLY to objects matching
the request URI, which MUST be treated as opaque strings and MUST
follow URI string comparison rules as defined in Section 3.2.3 of
RFC2616. Where a receiving cache is capable of storing multiple
variants of a URI, all objects matching the request URI MUST be
deleted unless conditional request headers indicate otherwise. This
document does not make any provision for supporting the deletion of
multiple object by use of wildcards or regular expressions.
Absence of the object specified in the request URI within the cache
receiving a purge request SHOULD NOT remove that cache's
responsibility to propagate the request.
3.1 Trivial Purge
Trivial purge messages are transmitted in ICPv2 messages (we assume
UDP as a transport medium). The structure of these messages is
identical to that of an ICP_OP_QUERY, as defined in RFC2186. The
opcode for ICP_OP_PURGE is defined as:
Cooper Expires December 30, 1999 [Page 6]
Internet-Draft Inter Cache Extensions July 1999
Value Name
----- -----------------
14 ICP_OP_PURGE
Note: There is NO CHANGE to the ICP version number - this is a
minor extension to ICPv2.
Where possible, requesting caches SHOULD use the "Requester Host
Address" in ICP_OP_PURGE to identify the origin of the purge
request. This may include the IP address of the origin server where
the message is being forwarded by a cache acting as a broker for
such messages. The requester host address MUST NOT be modified if
the message is relayed to another cache.
3.2 Decisive Purge
Decisive purge messages are transmitted as HTTP/1.1 requests using a
new method, PURGE, to guarantee their delivery. The PURGE method is
an inter-cache method and MUST NOT be sent to an origin server.
Note: Does the HTTP Extension Framework[4] provide a suitable
alternative to defining a new protocol method?
Note: While the semantics of the DELETE method closely match
those of PURGE, the possibility of mis-interpretation of using
DELETE is too great. Extending the protocol was deemed the safest
way to avoid undesirable interactions.
The Max-Forwards request header MAY be included in PURGE requests to
enable the maximum extent of any propagation to be limited.
Conditional request headers (e.g. If-Unmodified-Since,
If-None-Match) MUST be propagated with the PURGE request where these
are present.
We recommend the use of If-None-Match with known fresh ETags to aid
receiving caches remove stale content.
The From request header SHOULD contain the email address of the
human administrator ultimately responsible for issuing the purge
request.
3.2.1 Valid HTTP response codes for PURGE
200: OK: the purge request was accepted
400: Bad request: SHOULD only be returned by caches not implementing
the modifications given in this working document
403: Forbidden: The request was not completed, and authorization
Cooper Expires December 30, 1999 [Page 7]
Internet-Draft Inter Cache Extensions July 1999
will not help. Returned when the receiving cache refuses to
handle PURGE requests
404: Not found: the purge request was accepted but the URI specified
was not in the cache. (A 404 status is favored over 204 since the
requesting cache may treat the absence of content as an "error"
if it attempting to track the content of each cache it contacts.)
407: Proxy authentication required: authentication is required by
the receiving cache
Cooper Expires December 30, 1999 [Page 8]
Internet-Draft Inter Cache Extensions July 1999
4. Removal of URL from ICP replies
To help improve the efficiency of ICP, and its handling within
caches, the payload of ICP replies may be modified to remove the the
request URL from responses. The use of ICP_FLAG_DONT_NEED_URL in a
request (and the corresponding response) indicates that the
requesting cache is capable of receiving a reply in which the
request URL is not supplied. A cache MUST reply with a standard
ICPv2 response if ICP_FLAG_DONT_NEED_URL is not present in the
request, but MAY include the flag in its response.
ICP option flags:
0x04000000 ICP_FLAG_DONT_NEED_URL
This flag may be set in an ICP_OP_QUERY message to indicate that
the querying cache does not require the URL in the reply message.
The querying cache can use the reply's REQNUM value to identify
the object for which the query was sent.
This flag MUST be set in an ICP_OP_HIT, ICP_OP_MISS, or
ICP_OP_MISS_NOFETCH message where the URL in the reply has been
omitted due to the corresponding query having the same flag set.
Cooper Expires December 30, 1999 [Page 9]
Internet-Draft Inter Cache Extensions July 1999
5. Security Considerations
The threats associated with passing purge requests between caches is
obvious. However, in writing these extensions interested vendors
were happy to support remotely requested purge operations where only
single URIs are considered.
For the most part the security considerations of these proposed
extensions are covered by the underlying protocols. The following
sections outline additional security considerations.
5.1 Via header
Providing product version information in the Via header may allow
third parties to exploit known security holes. RFC2616 recommends
that a pseudonym be used where the received-by field would otherwise
contain sensitive information.
5.2 Trivial purges
The documented susceptibility of ICP to IP address spoofing [3]
means that ICP_OP_PURGE operations are susceptible to the insertion
of purge messages by unknown third parties.
During the development of these extensions, cache vendors indicated
that they were not worried at the prospect of this threat so long as
wildcard purges were not required. Further, that where problems
existed it would be possible to ignore trivial requests in favour of
authenticated decisive requests.
5.3 Decisive purges
We strongly recommend the use of digest proxy authentication between
co-operating caches.
5.4 Removal of URL from ICP replies
Caches become particularly susceptible to in-transit modification of
ICP request numbers (RFC2187 Section 9.7) if the URL is removed from
replies. Such modification would be similar to blocking of the ICP
reply altogether.
Caches not supporting these protocol extensions are susceptible to
in-transit modification of the ICP options field. In-transit
switching of ICP_FLAG_DONT_NEED_URL may result in the requesting
cache having insufficient data to understand a reply.
Cooper Expires December 30, 1999 [Page 10]
Internet-Draft Inter Cache Extensions July 1999
6. Acknowledgements
At the time of writing, the Inter-Cache Group comprised
representatives from the following organisations: Mirror Image
Internet, Cobalt Networks, Entera, Network Appliance, Inktomi
Corporation, Netscape, Novell, n2h2, Cisco, Cacheflow, and
Infolibria. We thank these organizations for their help.
Thanks also to Duane Wessels for co-ordinating modifications to
ICPv2, and to members of the IETF WREC Working Group for their
comments on the draft at IETF45 (Oslo).
Cooper Expires December 30, 1999 [Page 11]
Internet-Draft Inter Cache Extensions July 1999
References
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[2] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
Version 2", RFC 2186, September 1997.
[3] Wessels, D. and K. Claffy, "Application of Internet Cache
Protocol (ICP), version 2", RFC 2187, September 1997.
[4] Frystyk Nielsen, H., Leach, P. and S. Lawrence, "HTTP Extension
Framework", Internet Draft draft-frystyk-http-extensions-03,
Mar 1999.
Author's Address
Ian Cooper
Mirror Image Internet
18 Commerce Way
Suite 4800
Woburn, MA 01801
USA
Phone: +1 800 353 2923
EMail: ian@mirror-image.com
Cooper Expires December 30, 1999 [Page 12]
Internet-Draft Inter Cache Extensions July 1999
Appendix A. Inter-Cache Mailing List
The Inter-Cache mailing list was established to enable interaction
between caching vendors and other interested parties wishing to
become involved in developing new cache co-operation protocols. The
list is independent of any cache vendor.
Subscriptions are moderated, but the list is open for general use by
subscribed members. You may subscribe by sending a message to
majordomo@caching.org with the body "subscribe inter-cache".
Messages for the group should be sent to inter-cache@caching.org
Cooper Expires December 30, 1999 [Page 13]
Internet-Draft Inter Cache Extensions July 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Cooper Expires December 30, 1999 [Page 14]