The concept of a friendly URL is a pretty simple one. Basically you want to make things in your application, on your website, etc. easier to access. This stems from the fact that most applications these days make use of increasingly complex paths for a multitude of reasons. Whether it’s user specific content, auto generated pages or otherwise, typing in a URL that looks like “http://domain.com/a7391/users/0928179/events/live/release/20110403/regions.php?region=atl” isn’t something that’s easy or frankly even realistic for a user. I’m not going to remember that URL, and if I’m an 8 on the geek scale, certainly the 3s and 4s of the world won’t be able to manage that kind of a URL either. Nevertheless, these sort of paths are common amongst robust applications.

Enter friendly URL redirection. To combat the plague of uncivilized URLs many people, including DevCentral, turn to friendly URL redirection. That is, they make up a shorter, more usable URL and hand that out to users instead. Then, when a user accesses that URL, they get directed to the appropriate content. For instance, using the example above of a make believe user group in Atlanta “http://domain.com/ug/atl” might very well redirect me to the appropriate URL while being something humans can actually remember and reproduce when it comes time to type in a URL. To make this process even easier this is something that iRules can handle very smoothly. Simple HTTP::redirect lists in a switch or the like work great for getting started with this process, something like:

when HTTP_REQUEST {
  switch -glob [string tolower [HTTP::uri]] {
    "/ug/atl" {
      HTTP::redirect "http://[HTTP::host]/a7391/users/0928179/events/live/release/20110403/regions.php?region=atl"
    }
    "/ug/sea" {
      HTTP::redirect "http://[HTTP::host]/a2416/users/0622375/events/live/release/20100602/regions.php?region=sea"
    }
  }
}

A very simple example, but you get the idea. Look for the short URL, redirect to the appropriate (usually longer, more complex) URL. All right, that’s well and good, but where does the scaling come into play, you ask? Well this concept is fine and dandy for 2 or 3 or even up to say 10 or 15 redirects. What if you have 100? 1000? Are you going to maintain a switch with 1000 cases? If your answer was yes turn off your computer, and go seek professional help. For those that are still here…of course you’re not. You’re going to find a way to make that management much simpler and re-use more generic logic.

As with most cases in an iRule when someone tells me they need to store several (more than a hundred, less than a million) records and parse through them at will, here will be using a class. With the semi-recent improvements to classes in both performance and scale they’re suited wonderfully to this kind of task. What we’ll need is a class that contains these mappings and some simple logic to parse the class, recall the key->value info as necessary and redirect based off of that. First the class:

   1: class "redirurls" {

   2:   "/ug/atl" {"/a7391/users/0928179/events/live/release/20110403/regions.php?region=atl"}

   3:   "/ug/sea" {"/a2416/users/0622375/events/live/release/20100602/regions.php?region=sea"}

   4:   "/ug/nyc" {"/a1753/users/0524611/events/live/release/20100714/regions.php?region=nyc"}

   5:   "/ug/la" {"/a6542/users/0316327/events/live/release/20100312/regions.php?region=la"}

   6: ...

   7: }

This could go on for however many entries you want, obviously. Also note that not all of them must be in the same format. It’s just coincidence (and efficiency) that my examples all look the same. It could be any incoming URI you want to redirect. Now that we have a class to parse, we need an iRule to do the parsing. This is a pretty simple setup but that’s kind of the idea:

   1: when HTTP_REQUEST {

   2:   set newuri [class match -value [string tolower [HTTP::uri]] equals redirurls]

   3:   if {$newuri ne ""} {

   4:     HTTP::redirect "http://[HTTP::host]$newuri"

   5:     unset newuri

   6:   }

   7: }

As you can see the actual iRules code required is extremely simple. All you need is a class match to return the value in the class when searching based on the URI that’s coming in. If there’s a match, the HTTP::redirect fires and sends the user to the appropriate URI and they’re on their way. There are hundreds of tweaks, customizations and embellishments that could be made here, so feel free to think outside the box. This is just a basic look at the concept. From here the sky’s the limit.

So there you have it, a scalable way to handle Friendly URL Redirection via iRules.

Friendly URL Redirection Scaling via iRules