iRules:

iRules:

     iRules is the script which influences the traffic which flows through the BIG-IP if the script matches for the traffic. Commonly iRules are used to select the pool to process a client request. This is technically called as a UNIVERSAL INSPECTION ENGINE (UIE). 

BIGIP F5 iRules — What are they?

What is an iRule? What are iRules? What can I do with iRules? What is an iRule example?

One of the most advantageous features that an BIG IP F5 Local Traffic Manager brings is it’s iRule feature. This feature allows the F5 to manipulate and perform event driven functions to the application traffic as it passes through the F5 LTM. This is very useful and has many use cases. For example, a common iRule is as follows. Let’s say you have a typical load balancing setup, with 5 web servers being balanced in a round robin fashion. The traffic that passes through is HTTP. For security purposes only HTTP-SSL is allowed to this site, however you don’t want users to have to remember to put https:// rather than http:// in their internet browser’s address bar. Instead of putting a redirect page on the port 80(insecure) instance on each of the 5 web servers, a simple iRule will take care of that!

Example HTTP to HTTPS redirect iRule:

When we look at this iRule we see a few things. We see an event that must be triggered in order to for the iRule to execute, “when HTTP_REQUEST“. Next we see a HTTP redirect function being performed with a few parameters. HTTP::redirect is the function and the target URL string “https://[HTTP::host][HTTP::uri]”. Let’s break this statement down as it is the meat and potatoes of the iRule.

https:// is what protocol to send the users browser when it performs the redirect.

[HTTP::host] which is derived from the clients host-header as it comes across to the F5 LTM. The host header is set when you open a new browser and type the domain/host you are requesting to go to. For example, if you type http://www.google.com in your browser, when you hit enter in the HTTP stream the host-header is set to www.google.com. This is essential when using SSL, but more on that in another post.

[HTTP::uri] the last part is the URI the user is trying to GET. If this is a standalone site such as www.mysite.com, usually users will hit that first and be redirect already via our iRule before they browse to any URIs. However, perhaps a user tries to go to http://yousite.com/URI, they are not coming across HTTPS so the iRule will intercept it and redirect them to https://yoursite.com, but wait we don’t want them to get kicked back to the root of the site, so the [HTTP::uri] is appended to the redirect target string.

URIs vs URLs:
You will see people use these interchangeably, or used in-properly. Even Wikipedia’s article on them is confusing. Since I’ve been an IT engineer working in web-centric environments a URI is what is appended at the end of the host or FQDN, and a URL is the whole thing.

So,
http://en.wikipedia.org/wiki/Computer

FQDN = en.wikipedia.org
URI = wiki/Computer
URL = http://en.wikipedia.org/wiki/Computer