Log applet

When the proxy serves a client request from its cache, it does not inform the server about this request. Therefore, servers can not collect access information for their documents that are cached in proxy. The purpose of this applet is to log such accesses into a log object (in the proxy), which will be later sent back to server.

The applet saves the access information into a log object in the ActiveCache proxy. This applet first checks whether a log object exists in ActiveCache proxy. If not, it creates a log object. Then the applet writes the access information (including time, client domain name, client IP address, client request) into the log object. Here  is an example applet.

Advertising Banner Rotation applet

Server may change the presentation of the same document upon every request, for example, putting on different advertising banners in the document. This applet simulates what the server does in this case. For each request that hits in proxy cache, the applet insert some advertising banners into the cached document to create a new document. Proxy returns this new document to client. Therefore, each time the client requests this document, it may see different advertising banners in the document. Here is an example applet.

Specifying the position of rotation banner in document

The positions for inserting rotation banners are specified in the cached document with the following syntax:
<!-- Begin Rotate Banner Position <i> -->
some other html lines
<!-- End Rotate Banner Position <i> -->
Here, <i> represents a number, which differentiates different positions for inserting rotation banner in the document. When the cache applet is invoked, it scans the cached document for the above pattern. If a pattern is matched, it replace the matched pattern with one corresponding rotation banner.

Specifying the rotation banners

To know what rotation banner to be inserted into the document, the applet requires the server to supply a specification file whose URL is the document's URL appended with .ads.obj. For each position in the document, the specification file specifies the rotation banners that may be inserted in this position and the probablity of inserting each rotation banner. The specification for one position in the file is as following:
Position <i>
<probability_1> <rotation_banner_1>
<probability_2> <rotation_banner_2>
... ...
<probability_n> <rotation_banner_n>
Here, <i> is a number specifying the position. <rotation_banner_i> is one possible rotation banner for this position. <probability_i> is the occurence probability of <rotation_banner_i> in this position. When the applet is invoked the first time, it retrieves this specification file from the server and saves it as an object in ActiveCache. When the applet runs, it first reads the specification file and insert advertising rotation banners accordingly.

Seed object for generating random number

Each time the applet need to choose a rotation banner for one position, it generates a random number and makes choice according to the specified probabilities and the random number. That is, the choice made for one position is dependent on the generated random number. The applet should generate different number change on different invocations, so the random number generator should use different seeds each time.

The applet creates a seed object in ActiveCache for itself. The seed object contains a set of seeds, one seed for each position in the document. When the applet starts running, it reads the seeds from the seed object. Whenever it wants to generate a random number, the random number generator uses the seed of the corresponding position, then the seed for this position is changed so that it will be different next time. Before the applet finishes, it saves the updated seeds to the seed object.

Server-Side Include Expansion applet

Similar to the advertising rotation banner applet, this applet allows expansion of Server-Side Include (SSI) variables at the proxy site, thus allowing the correct caching of SSI-based dynamic documents. The applet scans the cached document and looks for SSI pattern, which is like:
<!--#echo var="<VARIABLE_NAME>"->
Here, <VARIABLE_NAME> is a SSI variable, which can be DATE_GMT, DATE_LOCAL, REMOTE_ADDRESS, REMOTE_HOST.  The applet replaces the SSI pattern with the corresponding value of its variable to create a new document. Proxy returns the new document to client.  Here is an example applet.

Access Permission Checking applet

The purpose of this applet is supporting the access control to documents cached in proxy. The applet make access control decision based on the content of client request. If the client request contains the correct certification, the applet lets ActiveCache return the cached document directly to client. Otherwise, the access to cached document is not granted. ActiveCache redirects the client request to server. Here is an example applet.

Checking the cookie header

The certificate in the client request is a cookie header of the form:
Cookie: ID=<id_string>; SIGNATURE=<signature_string>
<id_string> is an arbitrary string, <signature_string> is a generated signature using <id_string> as data. The applet checks that the client request contains the above cookie header and verifies that <signature_string> is the correct signature on <id_string>. If the client request contains the correct certificate, applet just returns 0, which means ActiveCache proxy should return the cached document directly to client. Otherwise, applet returns -1, which means ActiveCache proxy should forward the client request to server and send server's response back to client. In the later case, cached document in the proxy is not accessed by the client.

Getting the public key from server

The applet uses the public key from the server to verify the signature. It requires the server to provide a file which contains the public key. The URL of this file is the URL of the document appended with .pubkey. When the applet is invoked the first time, it retrieves this file from the server and saves it to an object in ActiveCache proxy. Applet reads the public key from the object and uses it to verify signature.

Client-Specific Information Distribution

The purpose of this applet is to allow proxy to cache and send client-specific pages to clients. Today, many information providers allow users to specify preferences on the categories of information to receive. Users specifies their preferences from a web page, which are saved into a preference database on the server. When user access the server again, server figures out the user from its request and send a page customized according to user's preference. This applet is to support this functionality in the proxy.  Here  is an example applet.

Identifying the user

After user specifies his/her preferences to the server, server sends a cookie to the user's browser. Assume the cookie is accepted by the user's browser, the browser will send this cookie header in all its later request. Therefore, the server can identify user from the cookie headers in the request. The applet identifies the user in the same way, it examines the client request for a cookie header of the form:
Cookie: userId=<id>
If this header does not exist, the request is not sent by a known user, the applet returns 0 and let the ActiveCache proxy return the cached document to client. If the header exists, the applet first looks up the preferences of the user. Then it generate a HTML document based on user's preferences.

Looking up the preference database

The applet looks up the user preference database by invoking a script on the server. It requires the server to set up a CGI script that preforms the database lookup and returns its result. Specifically, it sends to the server a requrest GET /cgi-bin/get_prefs.cgi?userId=X HTTP/1.0 and use the server's response as the preferences for user X. After the applet gets the preferences, it saves them into a preference object in ActiveCache to avoid getting them from server every time.

Constructing the new document

The user's preferences are basically a set of topics that the user is interested in. For each possible topic, the server keeps one HTML document that contains a set of links related to this topic. When the applet gets the user's preferences, it loads each corresponding HTML documents from the server and save it as an object in ActiveCache. Then it combines these HTML documents into a new HTML document, which will be sent to client. Thus, user will see a HTML page that contains links of his/her preferences.