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 I've got a combination of entries from our awesome forum users, and a rule I wrote a while back to meet a certain need at the time. We're almost at 10 editions of the 20LoL, and I'm looking forward to many more. Hopefully you're still finding it interesting and useful. Shoot me a line and let me know what's good, what's bad, what can be better and what you want to hear about.

In the meantime, here's this week's 20 Lines or Less


Multi-Conditional Redirect


Hoolio delivers this short and sweet iRules in the forums to show how you can use multiple pieces of data to decide when to perform a redirect.  Not only does he make use of a normal string comparison, but also an IP::addr comparison against the client's IP address. So in one line you're getting two comparisons on two different pieces of data. This is a good example for someone looking to redirect only a small subset of people, based on multiple pieces of data.

   if { [string tolower [HTTP::path]] ends_with "/_grid/print/print_data.aspx" \

   and (not ([IP::addr [IP::client_addr]/8 equals]))} {
      HTTP::redirect "


Syslog Priority Rewriting

This is a variation on some actual code I wrote a while back to translate the syslog priority numbers when needed.  Depending on the different syslog configurations, these numbers may not line up. This can be a problem when you're trying to aggregate many syslog systems into one main log server. This iRule shows how you can catch these messages inline and modify them with whatever equation fits your environment.

  set pri [regexp -inline {<\d+>} [UDP::payload] ]
  set newPri [expr ( ($pri - (($pri / 6) * 8) ) ) ]
  regsub $pri [UDP::payload] $newPri newPayload
  UDP::payload replace 0 [UDP::payload length] $newPayload


Duplicate Cookie Definitions


Going back to the forums, it seems that hoolio is at it again. In this cool example he shows a fellow community member how to check for and remove multiple Set-Cookie entries with the same name.  This way they can ensure that there is only one cookie present, regardless of how many times different apps may have tried to set it. This one looks a little long, but remove the comments and some of the white space, and it's under 20 lines...I checked.

 when HTTP_RESPONSE {   

# Insert some test response headers
HTTP::header insert Set-Cookie {SESSIONID=AAAAAAAA; domain=.domain.com; path=/path/1}
HTTP::header insert Set-Cookie {keeper=don't delete; domain=.domain.com; path=/path/2}
HTTP::header insert Set-Cookie {SESSIONID=BBBBBBBB; domain=.domain.com; path=/path/3}
HTTP::header insert Set-Cookie {SESSIONID=CCCCCCCC; domain=.domain.com; path=/path/4}

log local0. "Set-Cookie header values: [HTTP::header values Set-Cookie]"
log local0. "First Set-Cookie header which starts with SESSIONID: \
[lsearch -glob -inline [HTTP::header values Set-Cookie] "SESSIONID*"]"
log local0. "Last Set-Cookie header which starts with SESSIONID: \
[lsearch -glob -inline -start end [HTTP::header values Set-Cookie] "SESSIONID*"]"

set set_cookie_header [lsearch -glob -inline -start end [HTTP::header values Set-Cookie] "SESSIONID*"]
log local0. "\$set_cookie_header: $set_cookie_header"

# Remove all SESSIONID cookies
while {[HTTP::cookie exists SESSIONID]}{
HTTP::cookie remove SESSIONID
log local0. "Set-Cookie values: [HTTP::header values Set-Cookie]"

# Re-insert the last SESSIONID Set-Cookie header
HTTP::header insert Set-Cookie $set_cookie_header

log local0. "SESSIONID cookie: [HTTP::cookie SESSIONID]"

There you have it, 3 more examples in under 60 lines of code. Keep checking back every week to see what cool things can be done in just a few keystrokes. Many thanks to the awesome community and the people posting these examples. You're truly making DC a great place to be.