The Active Cache protocol allows a rich variety of processing to be accomplished at the proxy system. Below, we describe the applets we have implemented.
Logging User Accesses
One of main reasons many Web server disables caching is to collect information on who access their documents. Both server and proxy suffer from such practice, as the former has to buy a lot of resources to handle the volume of incoming requests, and the latter has to pay for the Internet traffic. Active cache solves the dilemma by using a log applet.
We have implemented a log applet, whose FromCache method simply writes the client IP address, the date of the access, and the HTTP request to the log object. The applet is assured that the log object will be sent back to the server eventually. The Java code looks like the following:
public static int FromCache(
String User_HTTP_Request,
String Client_IP_Address,
String Client_Name,
int Cache_File,
int New_File) {
int fd = open("logapplet.log", APPEND_ONLY);
int status = lock(fd);
String date = new curtime();
log_to_file(fd, date, Client_Name,
User_HTTP_Request, Client_IP_Address);
status = unlock(fd);
close(fd);
return(0); // 0 means use the cached file
}
Advertising Banner Rotation
Another reason that servers disable caching is to change the presentation of the document upon every request, for example, putting on different advertising banners. This again conflicts with proxy caching. Active Cache solves the problem by attaching an ad-banner-rotation applet with each document.
The applet, when invoked, first checks for the object that specifies the banners, their positions in the document, and their frequencies of appearance. If the object is not in cache, it sends a request to the Web server to fetch the object. The applet then goes through the cached document, and for every image that is specially marked to be an advertisement banner, decides which banner should be put there according to the specifications, and changes the image URL. It then puts the new document in the New_File and returns 1.
The applet implements a simple frequency-based rotation. Other algorithms can be implemented. The applet can recode the state needed by the algorithms in the object. It can further record the banner choices it made in the log object.
Access Permission Checking
Existing caching systems for the Internet typically provide only very limited support to access control of server information: for example, only allowing the same user to access the document again. Using cache applets, the server can gain the benefits of proxy caching without sacrificing the access control.
The cache applet, upon receiving a request from the user, checks whether the user request is accompanied with an access authorization. An access authorization is a cookie that contains a signed statement from the server. If not, the request is sent to the server (whose response would include a cookie for future requests if the user is allowed to access the information). Otherwise, using the server's public key, the applet verifies whether the server has signed the certificate. If so, the applet grants access to the document. If not, the applet merely returns -1 and the request is redirected to the server, who will send the appropriate access violation messages.
Client-Specific Information Distribution
Today, many information providers allow users to specify preferences on the categories of information to receive. A typical example is my.yahoo.com, which is among the busiest site on the Internet. The client-specific pages currently cannot be cached at the Web proxies, increasing the load at the Web server and the traffic on the Internet. Active cache solves the problem again by using a cache applet that constructs client-specific pages based on a database of base documents.
We have implemented a simply cache applet for this purpose. Upon receiving the client request, the applet first probes a database object to see if it stores the mapping between the client ID (extracted from the cookie) and its preferences. If not, it fetches the preference from the server. After obtaining the preference, the applet composes the Web page. For each individual information item, it first tries to read the item from the cache, and if the item is not cached, fetch it from the server and cache it. It then returns the new page to the user.
Thus, the cache applet filters out the redundancy in the information transmitted by the server for the client-specific pages, and allows individual information items to be cached and reused by the proxy. For a proxy with a large client population, the savings in network bandwidth can be significant. It also allows schemes such as Pointcast [#!pointcast!#] to not have to write its own proxy servers, and support broadcasting schemes such as SkyCache [#!skycache!#].
Server-Side Include Expansion
Similar to the ad-banner-rotation applet, another applet allows expansion of Server-Side Include (SSI) [#!SSI-tutorial!#] variables at the proxy site, thus allowing the correct caching of SSI-based dynamic documents. The applet scans the cached document, and for each specially marked SSI variable, update the value of the variable in the document, and put the new document in New_File. The proxy can correctly expand variables DATE_GMT, DATE_LOCAL, REMOTE_ADDRESS, and REMOTE_HOST. Other SSI variables are typically related to the server and do not change from request to request.
Delta Compression
Studies [#!douglis-mogul:differencing!#] have shown that transmitting the changes (deltas) between the new and old versions of dynamic information can reduce network traffic significantly. Delta compression can be easily implemented with cache applets.
We have implemented an applet that upon receiving a client request, sends a request to the original server, including the current request and the last-modified-time of the document. After the server responds with the difference between the new document and the cached version, the applet constructs the reply to the client request using the diff and the cached version.
A similar cache applet can support delta compression of query responses. For example, a query of a particular company's stock quote can be handled by the applet, which simply asks the server for the number and then composes the Web page based on a cached response.