Would you like to discuss your environment with a knowledgable engineer?
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:
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”.
Origins are your primary application servers, which aiMobile accelerates. You must add at least one.
For more configuration options see aiScaler Administrator Guide.
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:
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.
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 servers – probably not what you’d want.