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, for

news.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 rewrite:
--------- 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 be

berry, 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 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.