Browse Prior Art Database

Method for Dynamic Cache Key Generation used to Allow for Pluggable Cache Content Generators Disclosure Number: IPCOM000223753D
Publication Date: 2012-Nov-28
Document File: 5 page(s) / 33K

Publishing Venue

The Prior Art Database


Disclosed is a method of generating keys for cached responses from an aggregation service that supports pluggable content providers. It defines a programming interface that content providers implement so that their content can be efficiently cached in responses that are aggregated with content from other source files from the same and other providers.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

Page 01 of 5

Method for Dynamic Cache Key Generation used to Allow for Pluggable Cache Content Generators

With a cache where content is provided by combining output from multiple content providers, and each contributes content to a single cacheable entity multiple times, a system is needed for generating keys for cache entries in a way that allows for pluggable cache content providers.

A web content aggregation service is an example of such a cache. The service accepts requests for a list of web resources, and these resources might include a number of different file types. The aggregation service processes the requested files (e.g., minification by removing white space and comments, etc.) and combines the requested output into a single response. In order to achieve acceptable performance characteristics, the generated output is cached so that if the same set of files is requested again, and the request parameters match those that were used to compose a response already in the cache, then the cached response can be returned. This requires that the service be able to create a cache key to identify the cached response so that it can be looked up again for subsequent requests.

The generation of cache keys is complicated by the fact that the minified output for the same file may vary depending on request parameters, which control minifier options, as well as certain types of content. An example of this is a JavaScript* minifier that removes unused JavaScript code based on a set of features specified in the request. The aggregation service does this using has.js feature detection. Has.js feature detection is growing in popularity in web applications and works by using code similar to the following:

if (has("feature-name")) {

    .... } else {

    .... }

If the request contains a set of feature names, then the JavaScript minifier component
of the aggregation service trims the JavaScript code that is returned in the aggregated response so that the dead code is removed in a way that maintains the integrity of the code. If this response is cached, then it can be reused only for requests that contain the same set of feature names and values. Not all the features specified in the request need to be taken into consideration. Only those features in the request that are actually tested for by the code being minified need be considered when determining if a previously generated cached response may be returned for a subsequent request. This is an example of a case where the cache key generated for the response containing this JavaScript file depends both on the request parameters (the feature list) and the content of the module itself.

In order to be extensible, the aggregation service allows for additional types of content


Page 02 of 5

providers to be added using an extension mechanism. These new types of content providers need to be able to influence the cache keys that are used to look up cached responses containing their content in a way that is appropriate for...