Loading ...

Would you like to discuss your environment with a knowledgable engineer?

Preferred communication *

Thank you. We will be in touch with you shortly

aiMobile basic configuration


  1. 1 aiMobile config – basics
  2. 2 Identifying User-Agents and rewriting signature
  3. 3 Configuring mobile and desktop sites–> see page 91 of the admin guide
  4. 4 Pre-fetch feature –> see page 144 admin guide

aiMobile config – basics

First of all, you’d need to set website name. Open /etc/aicache/aicache.cfg and find “website” section in the example configuration file and edit it. For example:

# Section header
hostname aiscaler.com # Main host name
cname www.aiscaler.com # Alternative name (exact match)
wildcard amazonaws.com
# Process all requests made to *amazonaws.com

For sites that can not be matched to any of hostname, cname or wildcard values in configuration file, aiMobile returns error “409 Webiste not found”.
Next you need to set caching rules. Effectively, you tell aiMobile that when a request’s URL matches a string, then the response could be cached for certain amount of time. Match could be exact, partial or regular expression-based. Regexp patterns are most powerful pattern matching mechanism. Few quick examples:

pattern \.php regexp 1m # cache for 1 minute, cache dynamic files with caution
pattern .css simple 7d no_log # cache for a week, do not log in acces log file

Origins are your primary application servers, which aiMobile accelerates. You must add at least one.

origin 80 # Google server as testing origin, replace it with your server

For more configuration options see aiScaler Administrator Guide.

Identifying User-Agents and rewriting signature

Occasionally you might have a need for User-Agent-specific URL rewriting.

For example when request is coming from iPhone, fornews.html, you might want to redirect such request to iphonenews.html, while requests coming for the same URL from Blackberries, you want to send to berrynews.html and so on. This is where you can use UA-driven URL rewrites. These work and are configured in two steps:

First, you need to configure UA rewrites. We’re trying to “compress” hundreds of different mobile user agent string into a more manageable and much smaller set (see elsewhere in this Guide for more detailed explanation of this feature). Here is the list of widely used UA strings with rewrites:

--------- aicache.cfg snippet -----------------
#Mobile platforms (Blackberries, iPhone/iPod, Android, Nokia, Win mobile)
ua_sig_rewr .*BlackBerry9.* berry9
ua_sig_rewr .*BlackBerry8.* berry8
ua_sig_rewr .*BlackBerry7.* berry7
ua_sig_rewr .*Android\s1.* droid1
ua_sig_rewr .*Android\s2.* droid2
ua_sig_rewr .*GoBrowser.* nokia
ua_sig_rewr .*SymbianOS.* nokia
ua_sig_rewr .*IEMobile.* iemob
ua_sig_rewr .*iPhone.* iphone
ua_sig_rewr .*Opera\sMini.* operamob
ua_sig_rewr .*Opera\sMobile.* operamob
#Desktop/Laptop browsers
ua_sig_rewr .*MSIE\s8.* ie8
ua_sig_rewr .*MSIE\s9.* ie9
ua_sig_rewr .*Chrome/1.* chrome1x
ua_sig_rewr .*Safari.* safari
ua_sig_rewr .*Firefox.* ffox
When ua_sig_rewr are specified, the rewritten UA string becomes part of response’s signature – for cacheable responses. You can see that by using inventory CLI commands.
Next, in the matching pattern section, you can specify a wildcard match string, that is to be matched against the rewritten UA string (in our case, these will beberry, iphone or android) and URL rewrite string.
For example:

pattern /news.html simple 30


ua_url_rewrite iphone /news.html /iphonenews.html

ua_url_rewrite berry /news.html /berrynews.html

ua_url_rewrite android /news.html /androidnews.html


You can also configure a rewrite to an absolute URL by configuring the rewrite string so that the rewritten URL starts with http: or https: In this case, matching requests will be redirected to the specified location.

Please note that both URL match and URL rewrite strings are regexp strings, so you have full power of regular expressions to accomplish complex rewrites, but the rewritten-UA match string is a simple wildcard search string and NOT a regexp string. Of course the UA-driven URL rewrites can only happen when User-Agent is provided in the request header.

As usual, you can use the provided pattest tool to test your match and rewrite patterns. To see before and after URLs, specify log_rewrite setting in global or website section of the configuration file. Please note that cacheable response signature is formed from the original request URL, but it is the modified URL that gets logged in the access log file.

Please note that when you enable both UA-driven URL rewriting/redirection (see below) and use ua_pattern settings, explained later in this document, the UA-driven URL rewriting and redirection happens first – as in it takes precedence over “plain” URL rewriting.

Please take care to not-redirect, by mistake, assorted search Bots and similar. For example, redirecting Google search Bot to a mobile version of your site will result in Google search for your content pointing to your mobile serversprobably not what you’d want.

US 1 (408) 744-6078   EU +44 20 7993 4587