20 Lines or Less #7
What could you do with your code in 20 Lines or Less? That's the question I ask every week, 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.
This week we've got some more great examples from the community. I've had the chance to sit in with some fellow F5 iRulers the past couple of days and wow, is it ever inspiring to hear all the things they're doing/seeing with iRules, and the kind of stuff heading our way in the future. The 20 Lines or Less series is meant to show off the cool things you can do with just a simple iRule and that list just seems to go on forever. What's not to love about that?
It seems more and more people are checking out the 20LoL each week, which is awesome, so keep on coming back to see what other cool things you can do with your iRule foo without breaking a sweat. Here's this weeks' dose:
JSessionID Persistence
http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=24165#24170
Like a childhood friend, this topic is one that I can always count on coming back to again and again. We laugh, we cry, we talk about "the way things were" ... it's beautiful, really. Honestly though, JSessionID persistence is a very common theme that repeats itself in the forums time and time again. The truth of the matter is there are only so many ways to address this problem, and F5's iRules offers one of the coolest, simplest ways of doing just that, so it's bound to be popular. Here's one example of just that courtesy of the forums.
when HTTP_RESPONSE {
if { [HTTP::header exists "jsessionid"] } {
set jsess_resp [findstr [HTTP::header "jsessionid"] "!" 1 "!"]
if { $jsess_resp != "" } {
persist add uie $jsess_resp
}
}
}
Cookie Based Virus Scan Decisions
http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=24045#24173
This cool example shows how a user is making use of a combination of information, including cookies and the HTTP URI, to determine whether or not incoming traffic needs to be passed through an AV gateway. The code itself is relatively straight-forward, but it's another great example of one of the many, many things you might use an iRule for that just doesn't have another clear, simple solution. Nice one.
when HTTP_REQUEST {
set ID [findstr [HTTP::cookie "CookieX"] "Cookie" 10 ";"]
set my_uri [string tolower [HTTP::uri]]
log local0.info "ID is $ID default pool is [LB::server pool] URI is $my_uri"
if {($ID equals "")} {
log local0.info "sending user to pool [LB::server pool]"
pool [LB::server pool]
} elseif { ($my_uri ends_with "/attachmentshare/upload.aspx") and not ($ID equals "")} {
log local0.info "URI contains $my_uri sending user to pool AVPool$ID"
pool AVG$ID
snatpool SNAT$ID
} else {
log local0.info "Cookie found sending user to Pool Pool$ID"
pool Pool$ID
}
}
Multi-Pass HTTP Redirect
http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=24124#24129
Power user hoolio is at it again! In his latest escapades he's helped dacrud come up with a solution that actually uses multiple passes through a single iRule to get the traffic sorted the way they want it. By first redirecting the request to change the hostname, then routing based on URI, this single iRule packs a 1-2 punch that's code-efficient, powerful, and inventive.
when HTTP_REQUEST {
if {not ([string tolower [HTTP::host]] eq "www.domain.com")}{
HTTP::redirect http://www.domain.com[HTTP::uri]
} else {
switch -glob [HTTP::path] {
"/us*" {
pool US_pool
log local0. "[IP::client_addr]:[TCP::client_port]: using pool US_pool"
}
"/au*" {
pool AU_pool
log local0. "[IP::client_addr]:[TCP::client_port]: using pool AU_pool"
}
default {
pool default_pool
log local0. "[IP::client_addr]:[TCP::client_port]: using default pool"
}
}
}
}
That's it for this week. Be sure to check back for more iRules under that magical 21 line mark next week. Until then, toss out some ideas or feedback and let me know what you're thinking.
#Colin