What could you do with your code in 20 Lines or Less? That's the question I ask (almost) 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.

Catching up with a couple weeks of iRules goodness, I've got some cool ones for you again this week. I'm happy to see people are adding plenty of handy iRules in the CodeShare. It doesn't just make my job of finding cool, succinct iRules easy, it makes your lives as iRulers easier, and that's far more important.  Keep it up guys, you're rockin'.  Here are a few more in under 20 lines for you:

 

HTTP Serverside Chunking For One Dot Zero Requests

http://devcentral.f5.com/wiki/default.aspx/iRules/HTTPServersideChunkingForOneDotZeroRequests.html

This is a pretty cool iRule that lets you control the HTTP version for the server side independently of that of the client side.  In doing so you're able to do things like turn on chunking or transfer encoding for the servers even if the clients don't support it.  This one is straight forward and quite handy, just like I like 'em.

when HTTP_REQUEST {   set orig_version 11   if {[HTTP::version] eq "1.0"} {      set orig_version 10      HTTP::version "1.1"   }}when HTTP_RESPONSE {   if {$orig_version == 10} {      HTTP::version "1.0"      if {[HTTP::header exists "Transfer-Encoding"]} {         HTTP::payload unchunk         HTTP::header remove "Transfer-Encoding"      }   }}

Http Response Based on Requested Uri

http://devcentral.f5.com/wiki/default.aspx/iRules/HttpResponseBasedOnRequestedUri.html

Another great example of simple things you can do with an iRule that can turn out to be extremely useful, this iRule responds to certain HTTP requests.  It only does so after parsing the original request, though, so you've got a little more control than just blind responses.  This could obviously be expanded to do just about anything you want, but the example given, acting as a pool member for testing, is pretty handy in its own right.

when HTTP_REQUEST {   set data {Some data or HTML to send to the client.  If you want to use variables in here, replace the curly braces with quotes.}   if {[string match {/[1-5][0-9][0-9]*} [HTTP::path]]}{      HTTP::respond [string range [HTTP::path] 1 3] content $data "a_header_name" "a_header_value"      log local0. "Sending [string range [HTTP::path] 1 3] response with $data"   } else {      HTTP::respond 200 content $data "a_header_name" "a_header_value"      log local0. "Sending default 200 response with $data"   }}

Return_default_favicon

http://devcentral.f5.com/wiki/default.aspx/iRules/Return_default_favicon.html

This iRule, which I talked about in one of our previous podcasts, caught my eye as an ingenious little code snippet that could prove quite useful.  All it does is perform the simple task of redirecting users to a given favicon.ico file, which may seem mundane. Given some experience as a server admin though, and knowing the different vectors requests come in from, the way different applications point to specific files without telling you, etc., this could prove quite the time-saver when it comes time to update your icon.

when HTTP_REQUEST  {#Thomas Schaefer, Better Software Solutions, Inc.# A crazy simple iRule to redirect any favicon.ico requests to the favicon on your homepage# This promotes a uniform presentation.# Note this could be expanded to server the data right from the iRule (think external data class)        if  {[HTTP::path] ends_with "/favicon.ico"}{                HTTP::redirect "http://www.mycompany.com/favicon.ico"        }}
 
Hopefully you've found some use in these pocket sized rules. I'll keep scouting them out and bringing them up if you'll keep using them. ;)
#Colin