Internet-Draft G.Manoj Document: draft-manoj-cachecontrol-00.txt January 16, 2006 Expires: July 21, 2006 An Extension to Cache-Control, HTTP/1.1 for group caching Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 July 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Cache-Control general-header field of HTTP/1.1 [1] is used to specify directives that must be obeyed by all caching mechanisms along the request/response chain. This document details an extension to the cache-control header to enable caching of resources for dynamic sets of users who are grouped under certain attributes. Also this document specifies user-defined header extensions of HTTP/1.1 [1], which allow these clients to be served from the group caches. G.Manoj Expires - July 2006 [Page 1] Internet-Draft Cache-Control extension, group caching January 2006 Table of Contents 1. Overview.......................................................2 2. The Role of Origin Server......................................3 3. The Cache-Control extension....................................3 4. The user-defined header extension..............................4 5. The Working....................................................4 5.1 The Client Request.........................................4 5.2 The Origin Server Response.................................5 5.3 Role of Caching Proxy......................................5 5.4 The follow-up client requests..............................5 6. Security considerations........................................6 References........................................................6 Intellectual Property Statement...................................6 Disclaimer of Validity............................................7 Copyright Statement...............................................7 Author's Address..................................................7 1. Overview The dynamic contents served to the web users need not be completely private. Many a times the less confidential dynamic resources accessed over the web are common to a group of users. It is the origin server which decides upon serving dynamic contents (possibly common to a group) to the web users. Since the accessed resources are not common to all the web users, they are not cached in the shared caches. If the dynamic content happens to be common for a group of users then caching these contents in a shared cache would reasonably improve the performance. If the group accessing this common resource is significantly larger then a higher degree of performance can be achieved through this group caching mechanism. The cache-control response directive of HTTP/1.1 [1] allows an origin server to override the default cacheability of the responses. This cache-Control header can indicate the "private" or "public" nature of a document. The 'public' indicates the response may be cached by any cache, and the 'private' indicates that all or part of the response message is needed for a single user and must not be cached by the shared caches. But cache-control header doesn't provide information about the documents pertaining to dynamic groups formed by dynamic set of users. The group is indeed determined by the origin server based on various attributes like time of request or types of users or user's credibility etc., and it is entirely origin server specific. Manoj Expires - July 2006 [Page 2] Internet-Draft Cache-Control extension, group caching January 2006 The following sections details how the caching for these dynamic groups can be achieved through the combination of cache-control extension and the user-defined header extension of HTTP/1.1 [1]. 2. The Role of Origin Server The Origin Server drives the group caching by including the cache- extension tokens in the cache-control and an user-defined header extension in the HTTP Responses. Lets consider an enterprise wishes to offer a discounted service to its clients who have a good cash payment history. The pages served to these good-clients are almost the same and hence the origin server can direct the proxies to cache these pages specific to the good-client group. So any follow-up good- client requests can be served from the group caches. To drive this, the origin server has to identify the good clients and tag them properly. To enable the proxy to cache the private documents specific to these dynamic groups, the origin server introduces a new cache-extension token "cache-group". The attributes based on which the cache-group is defined are entirely origin server specific. Once the cache-group has been defined and proxies have been directed to cache the documents specific to the cache-groups, a significant reduction in latency time can be achieved. Moreover the life time of these cache-groups have to be strictly defined by the origin server. Another important role of origin server is tagging the clients about the group they belong to. To achieve this a user-defined header extension "X-Cache-Group" for HTTP/1.1 [1] is introduced. These extensions are detailed in the following sections. 3. The Cache-Control extension HTTP/1.1 [1] allows an extension to Cache-Control directives, allowing additional extensions to act as modifiers to the base directives. Both the new directive and the standard directive are supplied, such that applications which do not understand the new directive will default to the behavior specified by the standard directive, and those that understand the new directive will recognize it as modifying the requirements associated with the standard directive. Manoj Expires - July 2006 [Page 3] Internet-Draft Cache-Control extension, group caching January 2006 We propose a new cache-extension token "cache-group" which would be used with the "private" cache-response-directive to give additional information on the served messages. The syntax for the extended primitive is as follows: Cache-Control = "Cache-Control" ":" "private,cache-group =" val val = quoted-string Example Cache-Control : private, cache-group = "group-1" 4. The user-defined header extension In order to tag the clients about the cache-group they belong to, we propose a user-defined header extension "X-Cache-Group". Once the origin server identifies the client ( usually on the first request), it tags the client using the X-Cache-Group header. The same attributes used to define the cache-group is used in determining the user type also. The syntax for this extension is as follows: X-Cache-Group = "X-Cache-Group" ":" "=" val Val = quoted-string Example X-Cache-Group : "group-1" This means that a particular client belongs to the group-1 and so the proxy can serve this client by the pages cached in the cache-group group-1 in the follow-up requests. 5. The Working Lets take the same example of good-client specified in section 2 and see how the extension headers are put into use. 5.1 The Client Request The end-users have to talk to the origin server at least once to know about the group they belong to. There is no modification in the client Request and it is as same as before. Consider an user who has a good record of cash payment to an enterprise requests for the daily Manoj Expires - July 2006 [Page 4] Internet-Draft Cache-Control extension, group caching January 2006 messages page. The Requests will look as follows. [only important headers are shown] POST /daily-messages/index.html HTTP/1.1 Host: http://www.company-1.com/ 5.2 The Origin Server Response The enterprise identifies the user based on authentication and on data mining for this particular user, it also identifies the user as a good-client. The server informs the client about the group it comes under through the user-defined header X-Cache-Group. Also being a less secure page the server informs the proxy to cache the served page under a specific group through the cache-control extension. The Response will look as follows. [only the important headers are shown] HTTP/1.1 200 OK Date: Mon, 10 Jan 2006 09:55:21 GMT Content-Type: text/html Cache-control : private, cache-group = "good-client" X-Cache-Group = "good-client" 5.3 Role of Caching Proxy On seeing the cache-group extension in the response from the origin server, the caching proxies can very well cache the pages for the specified cache-group good-client. If the proxies don't understand the cache-group primitive they can treat the messages as private. Thus the older proxies which don't understand this extension bypasses this functionality and working in a normal way. The cache server must return the X-Cache-group header to the end- users/clients. There is no max limit on the number of the cache- groups the proxy must provide the caching for. However it should atleast support caching for 25 different cache-groups at any point of time. 5.4 The follow-up client requests The follow-up client HTTP/1.1 Requests should carry the X-Cache-Group header given by the origin server and will look as follows. [only the important headers are shown] Manoj Expires - July 2006 [Page 5] Internet-Draft Cache-Control extension, group caching January 2006 GET /daily-messages/index.html/page-1.html HTTP/1.1 Host: http://www.company-1.com/ X-Cache-Group = "good-client" It is possible that some other users who are also good-client might have requested the same page and thus the page should be available under the cache-group good-client. The proxy verifies the X-Cache- Group header and thus can serve this request with the page-1.html from the cache-group of good-client after the normal expiration check on the cached pages. 6. Security considerations This proposal finds a way of caching the pages which are common to a set of users. A user of a particular group should not be served with the pages from the other cache groups. Content providers must bear in mind that there is no guarantee of a particular user agent honoring either the Cache-Control, or X-Cache-Group headers. Alternative measures should be taken if document confidentiality is important. References [1] Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", Request for Comments 2616, June 1999. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement Manoj Expires - July 2006 [Page 6] Internet-Draft Cache-Control extension, group caching January 2006 this standard. Please address the information to the IETF at ietf-ipr@ietf.org. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Author's Address G. Manoj Network Appliance Inc. The Estate, 6th Floor, 121 Dickenson Road, Bangalore - 560042 Email: manojpec@gmail.com Manoj Expires - July 2006 [Page 7]