28. Cache scripts¶

Suppose that there are two URLs that render the same page on the site:

https://www.supershoes.example/search/?shoe:color=red&gclid=9fjsdu0u    

https://www.supershoes.example/search/?gclid=0bjDdAt&shoe:color=red

and that page is different than the one at:

https://www.supershoes.example/search/?gclid=0bjDdAt&q=shoe-color:green

So, from the point of view of ShimmerCat, the first two URLs should receive the same rules, while the third should receive its own set of rules. How to be flexible enough to consider these type of cases? Here is where cache scripts help.

Cache script files have one simple function: to produce a key that can be used to index accelerator rules for pages which are essentially the same regarding static assets.

28.1. Where .cache-script files go?¶

Cache scripts are associated with views. Whenever there is a view, there can be a matching cache script, and the naming convention is as follows:

index.html  -> index.html.cache-script
__index.html -> __index.html.cache-script

As you may guess, whenever a particular view is used, ShimmerCat also looks for an associated cache script. If it finds it, it evaluates its contents on the context of this particular request, trying to derive a key which is then used to fetch push rules and priorities.

In the accelerator, .cache-script files can be set in one of two ways:

They can be created by hand in the views dir, and “pushed” (with sc_pack push ) to the accelerator. This is the best way to go if you know best which query strings end up making the page render differently. Or
The cloud service will eventually add default .cache-scripts to the views under /+target/, provided that the coordinated image loading pipeline runs for pages ushered by those views.

28.2. What’s in .cache-script files?¶

Lua modules, which are evaluated in our base Lua environment.

Here is an example cache-script:

local cache = {}

function string_starts(String,Start)
   return string.sub(String,1,string.len(Start))==Start
end

-- Special function, will be looked-up by name
function cache.extend_key(request)
   -- trace("extend-called")
   return request.uri_path.path .. ' ' ..
          string.match(request.uri_path.query,  "%w+:%w+=%w+")
end

return cache

The script must return a module with one function: extend_key This extend_key function should take into account relevant parts of the query string, cookies and so on, and return a page key. The page key is used to locate .push-hint blocks in Redis, with dynamically generated suggestions of assets to push.

The parameter request received by extend_key is a Lua table with the following members:

view_path: the view
uri_path: the uri path, expressed as a table with members path, query and fragment.
cookies: a dictionary of cookies
cache-control: the cache-control directive