One way to do this is called transparent header modification. How it works is a user will enter a URL in their browser such as “www.mycompany.com/bus/”, the request will come in to your BIG-IP and the information sent to your web servers can be redirected or rewritten to whatever you like. Here is an example:


when HTTP_REQUEST {
switch -glob [string tolower [HTTP::uri] ] {
"/bus/*" {
HTTP::uri "/greyhound/bus"
}
}
}


Using the iRule above, this is what happens to your incoming HTTP request. The request comes in and the URI is converted to lower case and then inspected to see if it begins with “/bus/”. The asterisk indicates a wildcard, so anything could come after “/bus/”. If it does begin with “/bus/” then the URI will be transparently modified or changed to “/greyhound/bus”. The clients browser will not be updated, but the URI that the BIG-IP passes on to the server will be “/greyhound/bus”. Basically it turns a request for this “www.mycompany.com/bus/myrequest” INTO “www.mycompany.com/greyhound/bus” Pretty cool huh?

Now lets say you want to do something a little more exotic. Lets use the iRule from above in a different way.


when HTTP_REQUEST {
set uri [HTTP::uri]
switch -glob [string tolower [HTTP::uri] ] {
"/bus/*" {
HTTP::uri "/greyhound/searchBus.do?stationName=[string range $uri 5 end]"
}
}
}


What is this one doing? Let say an HTTP request comes in for “www.mycompany.com/bus/texas”. Using the iRule above the web server would actually receive a request for “www.mycompany.com/greyhound/searchBus.do?stationName=texas”. The clients browser would still read “www.mycompany.com/bus/texas”. Like I said powerful and flexible.

If you are interested in more content regarding transparent header modifications a.k.a. redirecting users without changing their URL, then I recommend reading this article by Joe Pruitt on the DevCentral website http://devcentral.f5.com/weblogs/Joe/archive/2005/07/27/ModifyingUriWithoutRedirect.aspx

So that got me to thinking… how can someone do this in an iRule?  I have to admit I haven’t really looked into it that much previously because we utilize an ASM module running on a 4100 unit.  The 4100 can do a lot of different things regarding cookies such as checking if a cookie has been modified and if the cookie was obtained in a previous session.  I figured I would hit the AskF5 database to see what I could turn up and I uncovered this little gem:

when RULE_INIT {
set ::key [AES::key 128]
}
when HTTP_RESPONSE {
set decrypted [HTTP::cookie "MyCookie"]
HTTP::cookie remove "MyCookie"
set encrypted [b64encode [AES::encrypt $::key $decrypted]]
HTTP::cookie insert name "MyCookie" value $encrypted
}
when HTTP_REQUEST {
set encrypted [HTTP::cookie "MyCookie"]
HTTP::cookie remove "MyCookie"
set decrypted [AES::decrypt $::key [b64decode $encrypted]]
HTTP::cookie insert name "MyCookie" value $decrypted
}

There is definitely more to this, so you may want to go check out the full solution article here:  SOL7784.  There is also an awesome 2009 iRule Contest entry that you should check out here. The iRule you will want to look at is the Cookie Tampering Prevention iRule written by Henrik Gyllkrans.

A friend of mine supplied the image to the left.  I am thinking that it may have to be the official logo for my website!  Of course, had I known he was taking pictures of me with his cell phone I would have flexed a bit more…

Not buying that are you?  Well OK, maybe that is just what I look like in my mind!  Coming next week to “The F5 Guy” website, news and reviews straight from the Dallas SecureWorld Expo!

Now this was an afront to my logic!  My brain was so used to thinking “If this, then this”, that it really was hard for me to wrap my brain around how I was going to pull this off.  So of course, I did what any sane F5′er does when he is looking for an answer to a puzzle he cannot solve.  I turned to Devcentral and the community forums.  I dug around for a while and eventually I found an old 4.0 iRule where an individual had used the “not” Logical Operator.

So I gave myself a big slap on the forehead and muttered a Homer Simpson’ish “DOH!!”.  I later went on to discover that the “not” Logical Operator is well documented on DevCentral here.  Below is the simple iRule that has saved our company thousands of dollars, saved the help desk many man hours of labor, prevented users from going insane because of broken links and keeps things simple.  It is amazing how an iRule so simple, can have such a dramatic impact.  So, the next time you are writing an iRule, just think of all the things you could “NOT” be doing!


when HTTP_REQUEST {
if { not ([string tolower [HTTP::host]] contains ".mycompany.com")}{
HTTP::redirect "https://[HTTP::host].mycompany.com[HTTP::uri]"
}
}


Bearing in mind that I have the “Default Persistence Profile” set to use a profile other than cookie, here is the iRule that I wrote:

 when HTTP_REQUEST {
 set header_uri [string tolower [HTTP::uri]]
 if { [matchclass $header_uri starts_with $::aaa_uri] } {
 	pool aaa_Pool
 } elseif { [matchclass $header_uri starts_with $::bbb_uri] } {
 	HTTP::redirect "https://bbb.companyname.com/bbb/main/Main.jsp"
 } elseif { [matchclass $header_uri starts_with $::CITRIX_uri] } {
 	persist cookie insert "CITRIX_Cookie" "0d 03:00:00"
 	pool CITRIX_Pool
 } else {
   pool ccc_Pool
  }
 } 

The command persist cookie insert “CITRIX_Cookie” “0d 03:00:00″, tells the BIG-IP® to create a cookie named CITRIX_Cookie, give it a duration of 3 hours and insert it into the header of traffic going to the CITRIX_Pool.  If traffic going to that pool already has the CITRIX_Cookie in its header then persist the connection to the same pool member that it used last time.

Traffic going to the rest of the pools will use whatever persistence method is set in the “Default Persistence Profile”.  It is also possible to disable persistence to pools by using the persist none command.