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]