20 Lines or Less #6

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.

Continuing to draw from the forums, this week's 20LoL is packed with user-contributed goodness. From massaging packets to avoid app-server maintenance, to setting up a customer persistence/re-selection mechanism, we've got it all. This week the iRules range from exactly 20 lines, down to a scant 7 lines of code. Don't be fooled though, even that tiny 7 lines is the framework for a solution that really packs a punch.

This week marks the first time I made a modification to an iRule to get it in under the 20 line maximum. All I did was strip out some un-needed variables, things I would suggest to any user posting up an iRule anyway, so my conscious feels pretty clear. I think that's still fair game, don't you? Let me know and I'll go with the popular vote for next time.

Anyway, hopefully you're still digging the series as much as I am. Let me know if you've got any questions, comments or suggestions and I'll get to them sharpish. Before the minute-rice gets over cooked, and before the throngs of ravenous kittayz are unleashed to force me to quit talking and just deliver the 20LoL, here's this week's 20 Lines or Less.

 

304 Status and Content Dropping

http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&postid=23747&view=topic

iRules is all about application fluency, so when the need arose to help solve a problem that would otherwise have to be put into code on an otherwise stable application server, it was a natural choice to send iRules in to the rescue.  By forcing RFC compliance into a situation where some rules were being ignored, we've kept the client system happy and chugging along with an action packed 20 line iRule.

when HTTP_RESPONSE {
  if {[catch {HTTP::status} status] or $status == ""} {
    set status "-"
    HTTP::close
  } elseif {$status >= 400} {
    HTTP::close
  } elseif {$status == 304} {
    catch {unset hdrs}
    if [catch {HTTP::header names} headerNames] {
      lappend hdrs X-Error "noHeaderSent"
    } else {
      foreach hdr $headerNames {
        if { ! [catch "HTTP::header value $hdr" vals]} {
          lappend hdrs $hdr "$vals"
        }
      }
    }
    if [catch HTTP::respond 304 $hdrs err] { log local0. "RESPOND_304_ERROR: $ err" }
  }
}

Per-Service URI modification

http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&postid=23798&view=topic

In this simple looking iRule slumbers the power to re-write a custom URI for every different service being offered by your site/portal/etc. No longer will your users need to remember those long winded URLs or keep lengthy bookmarks. Provide them simple to remember, easy to use, short URIs that get translated as necessary by this simple iRule. Note that once you pass 20 or 30 translations a class may be cleaner.

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

Disable Persistence + Reselect on LB Fail

http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&postid=23226&view=topic

This awesome example of iRule foo allows the LTM to disable persistence and reselect a new member from an "outage pool" when the normal load balancing mechanism fails to assign a member from the default pool.  I admit I had to massage this one a little to help get it in under the 20 Line max, but it's nothing I wouldn't normally recommend for a rule anyway, so I remain guilt-free.

 when HTTP_REQUEST { 
if { ([HTTP::cookie exists "JSESSIONID"]) and ([active_members [LB::server pool]] > 0) } {
persist uie [HTTP::cookie "JSESSIONID"]
}
}

when HTTP_RESPONSE {
if { ([HTTP::cookie exists "JSESSIONID"]) and ([active_members [LB::server pool]] > 0) } {
persist add uie [HTTP::cookie "JSESSIONID"]
}
}

when LB_FAILED {
if {[active_members [LB::server pool]] == 0 } {
LB::detach
LB::reselect pool "sorry"
}
}
 

Five more days, three more iRules examples, one more edition of 20Lines or Less in the books. If any of you out there in user land want to see a solution to a problem, let me know. For that matter, if you just want to see if I can build a solution in less than 21 lines, toss up those suggestions too. Who knows, it could be fun.

Thanks for reading, and hope to see you next week.

#Colin

Published May 15, 2008
Version 1.0

Was this article helpful?

No CommentsBe the first to comment