Internet DRAFT - draft-manoj-cachecontrol
draft-manoj-cachecontrol
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]
