Wielding the Power of the Network to Better Applications Everywhere

Colin Walker

Subscribe to Colin Walker: eMailAlertsEmail Alerts
Get Colin Walker: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Sun Developer Journal, Java Developer Magazine

Blog Feed Post

Twenty Lines or Less #29

That's the question I ask (almost) every week

What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week for the devcentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

29 editions later and still going strong. The 20LoL is a testament to just how many different things can be done with iRules in just a few lines of code.  Just imagine the possibilities if this were the 30LoL.

This week I’ve got three more examples, all from the forums. Today we’ll cover dealing with port numbers in HTTP requests, checking pool status from within an iRule, and more fun with nested switching.  The community keeps putting out fantastic examples so I just keep on writing about them.  Keep it up.

Removing HTTP request port numbers


Hoolio came up with a trio if examples of how to deal with port numbers in your HTTP requests. All of them are good, depending on your situation, but I’m only going to highlight one here.  Go check out the forum post above to see the other two and get the context of the thread.

# Check if Host contains a colon
if {[HTTP::host] contains ":"}{
# Redirect client to requested host minus the port and preserve the original URI
HTTP::redirect "
https://[getfield [HTTP::host] ":" 1][HTTP::uri]"


Checking pool member status


User cmbhatt, another one of our power-users, came up with a very cool example of using the LB::select command and HTTP::respond to show the status of a selected pool member.  It even has a built in meta-refresh so you can continually monitor the status. Pretty neat stuff.

if {[HTTP::uri] eq "/status" } {
scan [LB::select] %s%s%s%s%d command current_pool command2 current_member current_port
eval [LB::select]
set response "<html><head><title>$current_pool Pool Status - [clock format [clock seconds]]</title><meta http-equiv='refresh' content='10; url=
if { [active_members $current_pool] < 1 } {
append response "POOL NAME:$current_pool<br/> CURRENT MEMBER:$current_member:$current_port<br/> STATUS: DOWN <br/></body></html>"
} else {
append response "POOL NAME:$current_pool<br/> CURRENT MEMBER:$current_member:$current_port<br/> STATUS: UP <br/></body></html>"
HTTP::respond 200 content $response "Content-Type" "text/html"

More nested switching and pool selection vs. redirection


This rule stemmed from cmbhatt, once again, then I went in and made some tweaks where I think it made sense, as you can see in the thread.  The idea is that the user is looking to do some inspection of first the host, then in some cases, depending on what the host is, the URI as well.  Based on what’s found either a load balancing decision is made or a redirect is issued.  This is yet another awesome example of how iRules can turn something that would be ridiculously tricky or even impossible elsewhere into something pretty straight-forward.

switch [HTTP::host] { 
"www.mydomain.eu" {
switch [HTTP::uri] {
"/" {  HTTP::respond 301 Location "
http://www.mydomain.eu/zz/index.html" }
default { pool mydomain_eu_pool    }
"www.mydomain.be" {
switch [HTTP::uri] {
"/" { HTTP::respond 301 Location "
http://www.mydomain.eu/be/zz/index.jsp" }
default { pool mydomain_be_pool }
"www.mydomain.nl" { HTTP::respond 301 Location "
http://www.mydomain.eu/nl/zz/index.jsp" }
"www.mydomain.fr" -
"mydomain.fr" { HTTP::respond 301 Location "
http://www.mydomain.eu/fr/zz/index.jsp }
"www.mydomain.lu" { HTTP::respond 301 Location "
http://www.mydomain.eu/lu/zz" }


There you have it, three more iRules to get you on your way in less than 21 lines of code.  Feel free to submit ideas, suggestions of feedback, as always.

Read the original blog entry...

More Stories By Colin Walker

Coming from a *Nix Software Engineering background, Colin is no stranger to long hours of coding, testing and deployment. His personal experiences such as on-stage performance and the like have helped to foster the evangelist in him. These days he splits his time between coding, technical writing and evangalism. He can be found on the road to just about anywhere to preach the good word about ADCs, Application Aware networking, Network Side Scripting and geekery in general to anyone that will listen.

Colin currently helps manage and maintain DevCentral (http://devcentral.f5.com). He is also a contributor in many ways, from Articles to Videos to numerous forum posts, to iRules coding and whatever else he can get his hands on that might benefit the community and allow it to continue to grow.