iRules

Mashup: SDBP Boston, Caching and iRules - oh my!

Colin Walker — Thu, 06 Nov 2008 17:28:20 GMT

Whew! It's been a whirlwind of a couple weeks. Between the annual F5 sales conference, where Joe and I presented to a bunch of awesome F5 techies, followed immediately by a very cool trip to present with the famed Lori at the SD Best Practices event in Boston, I've barely had time to do laundry, sleep in my own bed and feed my puppy. It's good to be back, but what cool stuff I got to see/hear/talk about!

The Software Development Best Practices (SDBP) conference was hawesome. It's great to be around so many people that get "it" and share the same geeked out passion for development, computing and cool technology that I do. While there I not only got to have several awesome conversations while hanging out in the F5 booth on site, but also got to give a fun Technical Session with Lori (which she mentioned before we left) which I think went over pretty well. It was F5's first time at this conference but hopefully not our last, as I think the audience is a great one to get in front of when talking about the amazing things that our gear can do to help extend the application. Whether it's via standard LTM features, iControl or iRules, it's almost always a killer story.

One of the many stories we told when talking about things we can do for the application was the Joyent / Bumpersticker application story. For those of you that haven't heard it yet, I highly recommend checking it out. We've got some pretty detailed info in the interview that Joe and I did with Jason, their CTO, which you can check out here. The short version is that Joyent scaled Bumpersticker app from Linkedin to over a billion pageviews a month, running on Ruby on Rails, and they couldn't have done it without F5 and iRules. How cool is that?!?

They did this via a combination of intelligent caching and a smattering of iRules that garnered an 80% reduction in application load (80%!!11), allowing them to get way more bang for their processing buck. This, along with some other cool conversations I had regarding caching and some of the things we can do with it, led me to put together a tech tip that begins to delve into the world of caching and iRules on the LTM. More detail will follow I'm sure, but this starts the journey at least.

That's all for now, more later as always.

Technorati Tags: SDBP,Caching,iRules,Joyent,LinkedIn,Facebook,Ruby on Rails,Colin Walker

Listening to: Alter Bridge - One Day Remains - One Day Remains

#Colin

20 Lines or Less #15

Colin Walker — Thu, 09 Oct 2008 00:29:05 GMT

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.

Finally back into the swing of the 20LoL, I'm happy to give you the 15th edition of this blog series. Today's offering is brought to you by me, F5, and the power of iRules (tm). Okay, not really (tm), but it sounded cool. I still find myself on a journey to seek out the coolest iRule tidbits that I can in hopes of bringing them to you and showing off just how much power you can pack into a minute amount of code in an iRule. This week's examples are nothing less than that, and hopefully you'll find at least one interesting, if not useful.

Advanced URI Rewriting

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

In this example of rewriting a URI we go well past a simple directory change or query rewrite. This example goes a little further into the realm of the possible to show you how to rewrite a UID that is a portion of a complex URI. Thanks to hoolio and the other iRulers that contributed.

when RULE_INIT {
   # Set a couple of test query strings
   #set source {a=123&k=456&uid=toto&h=789}
   #set source {uid=toto&a=123&k=456&h=789}
   set source {a=123&k=456&h=789&uid=toto}
   # Split the string into a list on the delimiter &
   log local0. "\[split \$source\ &]: [split $source &]"
   # Create a new query string
   set new_query_string ""
   # Loop through the list and create an array of parameters and values
   foreach param_value_pair [split $source &] {
      log local0. "\$param_value_pair: $param_value_pair"
      # If the current param value pair starts with uid=, then prepend it to the list of query string parameters
      if {$param_value_pair starts_with "uid="}{
         set new_query_string ${param_value_pair}${new_query_string}
      } else {
         set new_query_string ${new_query_string}&${param_value_pair}
      }
      log local0. "\$new_query_string: $new_query_string"
   }
   set new_query_string hxs=1&${new_query_string}
   log local0. "\$new_query_string: $new_query_string"
}

HTTP to HTTPS redirect on 401

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

This iRule is built for a very specific deployment scenario which displays some ... interesting behaviors. The requirement was to redirect back to the proper HTTPS URL for the site if authorization was required. This is done to ensure that things are secure where they need to be before allowing people to enter auth information. I know it's not the most straight-forward way of doing things, but this particular deployment didn't have another workaround, so iRules came to the rescue.

when HTTP_REQUEST {
   set host [HTTP::host]
   set uri [HTTP::uri]
}
when HTTP_RESPONSE {
   if {[HTTP::status] == 401]}{
      HTTP::redirect "https://$host/$uri"
   }
}

Multi-Host HTTP Redirection with Switch

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

This example is a slightly trimmed version of the one provided (by hoolio, yet again) in the forum post. It shows some great ways to use a single switch to match many different domains or partial domains when doing a redirect based on a host. The individual pieces are all pretty straight-forward, but it's a great example of how to build a single, elegant logic flow rather than a bulkier if/else chain.

when HTTP_REQUEST {
   log local0. "[IP::client_addr]:[TCP::client_port]: New HTTP request to [HTTP::host][HTTP::uri]"
   switch -glob [string tolower [HTTP::host]] {
      "*newlifepubs.com" {
         log local0. "[IP::client_addr]:[TCP::client_port]: Matched 1"
         HTTP::redirect "http://www.example.com/nlp"
      }
      "*mpd.example.org" {
         log local0. "[IP::client_addr]:[TCP::client_port]: Matched 2"
         HTTP::redirect "http://staffweb.example.org/mpd/index.aspx"
      }
      "staff.example.org" {
         HTTP::redirect "http://staffweb.example.org/"
      }
      "*movementseverywhere.example.com" {
         HTTP::redirect "http://www.example.org/"
      }
      default {
         log local0. "[IP::client_addr]:[TCP::client_port]: No match"
         discard
      }
   }
}

There's another 20LoL for your coding pleasure. Hopefully I've been able to fuel your desire to run out and whip up some awesome iRules yourself. Check back next week for more cool code!

Technorati Tags: 20 Lines or Less,HTTP Redirect,401 Auth Required,HTTPS redirect,Colin Walker

#Colin

20 Lines or Less # 14

Colin Walker — Fri, 29 Aug 2008 19:22:20 GMT

This week we've got three more fun examples of iRules goodness for you, thanks to the awesome community driving the forums and the CodeShare. As always the goal is to show off some of the things that you can do with iRules in less than 21 lines of code. Let's dig in:

Distribute Email by Source IP

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

From the wiki comes this handy showcase of pool switching based on IP address. Putting this to good use by distributing info to different mail pools is an even cooler idea, which is just what this iRule does.

when CLIENT_ACCEPTED {
   if { [IP::addr [IP::remote_addr] equals 10.2.0.0/255.255.0.0 ] }  {
     log local0. "Node IP address is: [IP::remote_addr] and sent to SMTP_clients_from_10.2"
     pool smtp_clients_from_10.2
   } else {
     log local0. "Node IP address is: [IP::remote_addr] and sent to SMTP_clients_from_elsewhere"
     pool SMTP_clients_from_elsewhere
   }

String Based HTTPS Redirect

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

Yet another cool twist on the simple HTTP redirect iRules we've talked about before, this one uses a Location header in the response as well as a class of URIs to pick from. Even though it's a variation on a theme, it's cool to see the ways people are doing things, and remind us all that we have LOTS of options when it comes to iRuling.

 when HTTP_REQUEST {  
    switch -glob [string tolower [HTTP::uri]] {  
      "*alumni/giving/gift/" -  
      "*alumni/giving/pledge/" -  
      "*alumni/directory/search.aspx" -  
      "*alumni/directory/update.aspx" {  
      # don't do anything... 
      }  
    default { 
       HTTP::respond 301 Location "http://[getfield [HTTP::host] : 1][HTTP::uri]"   
      } 
    }  
  }

HTTP Routing without HTTP Profile

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

This one is super cool (assuming it works..note that it's untested, but I like it anyway!). The issue here was that the user needed to inspect some HTTP information in a session without applying an HTTP profile to the Virtual Server. That means no HTTP:: commands. Oh no! Never fear, TCP::collect to the rescue!

 when CLIENT_ACCEPTED { 
   TCP::collect 
 } 
 when CLIENT_DATA { 
   set idx [string first " HTTP/1." [TCP::payload]] 
   if { $idx < 0 } { 
     if { [TCP::payload length] > 2048 } { 
        log local0. "ERROR! Could not find HTTP request in 2K! dropping..." 
        reject 
     } else { 
       # Not enough data yet; collect more 
       TCP::collect 
     } 
     return 
   } 
   set request [string tolower [TCP::payload $idx]] 
   log local0. "Got request: $request" 
   if { $request contains " /XXXXX" } { 
     log local0. "Sending to Pool_XXXXX" 
     pool Pool_XXXXX 
   } else { 
     log local0. "Sending to Pool_WWWWW" 
     pool Pool_WWWWW 
   } 
 }

Hot off the presses, that's this week's 20LoL. Tune in again next week for even more iRule endeavors.

Technorati Tags: 20 Lines or Less,iRules,HTTP,SMTP,Colin Walker

#Colin

20 Lines or Less #13

Colin Walker — Fri, 22 Aug 2008 23:35:17 GMT

After a couple of weeks out of the office, I'm back at it with your weekly dose of iRules goodness in under 20 lines. This week's 20LoL comes from the forums as well as the codeshare. We've got some great examples here, including one iRule that can be used to help augment an already existing LTM module and give it some extra functionality...cool stuff!

Blocking Content with iRules

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

This is a good example of a robust, logified way to block certain URI parameters from being allowed through to the back-end servers. Aaron's gone to the trouble to both document the code and the output heavily. That might not be the fastest possible solution in production, but it sure is nice for testing.

 when HTTP_REQUEST { 
  
    # Log a debug message with client IP:port and the class contents 
    log local0. "[IP::client_addr]:[TCP::client_port]: class \$::badStrings: $::badStrings" 
  
    # Check if the client IP is part of the hosts datagroup 
    if { [matchclass [IP::server_addr] equals $::Hosts]}{ 
  
       # Log a debug message indicating the client IP matched the Hosts class 
       log local0. "[IP::client_addr]:[TCP::client_port]: matched Hosts class \$::Hosts: $::Hosts" 
  
       # Check if the requested URI contains any known bad strings 
       if { [matchclass [string tolower [HTTP::uri]] contains $::badStrings]}{  
  
          # Log a debug message indicating the client matched the Host class and had a bad string in the URI 
          log local0. "Matched server IP and found bad string in [HTTP::uri]: \
entry# [matchclass [string tolower [HTTP::uri]] contains $::badStrings]"  
  
 	 # Drop the TCP connection	  
 	 drop  
       } 
    } 
 }

MSM Whitelisting

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

This codeshare entry shows how you can use an iRule to get even more out of MSM on your LTM. Oh how I love TLAs. By creating a whitelist of known good IP addresses in this iRule, you can skip MSM processing and wring even more performance out of your BIG-IP...nice!

  priority 1
  when CLIENT_ACCEPTED {  
    if { [matchclass [IP::client_addr] equals $::white_list] } {  
            log local0. "client: [IP::client_addr] found in white_list directed to http_test_pool"  
          pool http_test_pool  
          event disable all  
    }  
    elseif { [matchclass [IP::client_addr] equals $::black_list] } {  
              log local0. " client: [IP::client_addr] found in black_list directed to http_test_pool_2"  
          pool http_test_pool_2   
                     # or discard  
          event disable all  
    }  
  }

Search and Replace via iRule

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

This example shows some of the things that can be done via the stream profile and selectively enabling replacements via iRules. The stream profile gives you plenty of ability to do data swapping in-line with even more speed than writing out the logic by hand in an iRule. Definitely good stuff.

when HTTP_REQUEST {
set replace_content 0
if {[HTTP::uri] contains "/atoz/"} {
    set replace_content 1
}
}
when HTTP_RESPONSE {
if {$replace_content equals "1"} {
    # Disable the stream filter by default
    STREAM::disable
    # Check if response type is text
    if {[HTTP::header value Content-Type] contains "text" and [HTTP::header "User-Agent"] contains "***"}{
      # Replace
      STREAM::expression "@123@xyz@ @456@xyz@"
      # Enable the stream filter for this response only
      STREAM::enable
    }
}
}

There you have it, three more examples of iRules goodness in less than 20 lines each. See you next week.

Technorati Tags: 20 Lines or Less,iRules,HTTP,Colin Walker

#Colin

And all that jazz...

Colin Walker — Sun, 27 Jul 2008 19:46:48 GMT

It's been a while since I've been in the South. It's funny how some things came back almost immediately as fond memories. Even the heat and humidity felt comfortable from my years spent in Atlanta, so when I found myself in the midday New Orleans sun, it wasn't as bad as it would be for perhaps the average Seattle-ite with gills.

Today I arrived in The Big Easy to help put on the iRules course at our annual Partner Summit. This is my first trip to New Orleans, and as an avid jazz/blues fan I have to say I'm excited for more reasons than just getting to share the good word about iRules/iControl/DevCentral. I'm really hoping I get the chance to get out and check out some awesome music while I'm here. If I get to have some awesome food while doing it, all the better.

I'm even more excited because I get to be a co-presenter of some killer content (duh, it's about iRules, how could it be anything less?) with some really bright fellow F5ers, which should prove to be a truly hawesome experience. It's nice to feel so excited after having a little trepidation before coming down here.

It's not that I don't like to travel, I love it, I don't even mind the flying or the airports, it's just that when I get back I get to go under the knife for a minor surgery, and I couldn't quite seem to get that out of my head. Low and behold, though, this trip is proving to be just the thing for it. I'm having fun so far, even though I just got here, catching up with the other iRulers that I'll be presenting with, and generally relaxing and getting out of my head. That's a good thing, so yeah....awesome.

For any of you that might be attending, hope to see ya here! For those that aren't, I'll surely post more later.

Technorati Tags: DevCentral,iRules,Blues,Jazz,Colin Walker

#Colin

20 Lines or Less #12

Colin Walker — Thu, 24 Jul 2008 22:51:31 GMT

Here we go again, three more examples of the powerful and interesting things you can do with iRules in less than 21 lines. Dipping again into the forums, with a few tweaks here and there (don't worry, I stayed honest to the rule, just took out comments and extra case comparisons, that kind of thing), we've got an action packed 20LoL this week. Here we go:

SSL iRule on a non-SSL VIP

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

This is a great example of using a single iRule for both HTTP and HTTPS traffic. In the forum post Deb shows a cool trick to allow us to sneak SSL commands past the iRule interpreter so that they are there when we need them, if a cert is found, but aren't used when the connection turns out to be straight HTTP. Pretty cool stuff.

when HTTP_REQUEST {
HTTP::header replace ClientIP [IP::remote_addr]
if {[PROFILE::exists clientssl] == 1} {
    set cname "SSL::cipher name"
    set cbits "SSL::cipher bits"
    set cver "SSL::cipher version"
    HTTP::header replace SSLCipher [eval $cname]:[eval $cbits]-[eval $cver]
    if { [SSL::cert count] > 0} {
      HTTP::header replace SSLSubject [b64encode [X509::subject [SSL::cert 0]]]
      HTTP::header replace SSLClientCert [b64encode [SSL::cert 0]]
      HTTP::header replace WebProtocol "HTTPS-auth"
    } else {
      HTTP::header replace WebProtocol "HTTPS"
    }
} else {
    HTTP::header replace WebProtocol "HTTP"
}
}

Extracting DHCP Info

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

This example for extracting DHCP info is very specific. It's looking for option 82 (Support for Routed Bridge Encapsulation) which may not be particularly useful to everyone out there, but the example stands as a great display of how iRules can help you tear into almost any kind of data, even DHCP data, and make intelligent decisions or actions based on that. Sure, it might take some re-working for your purposes, but what a cool example to get started with!

when CLIENT_DATA {
binary scan [UDP::payload] x240H* dhcp_option_payload
set option 0
set option_length [expr {([UDP::payload length] -240) * 2 }]
for {set i 0} {$option != 52 && $i < $option_length} {incr i [expr { $length * 2 +2 }]} {
    binary scan $dhcp_option_payload x[expr $i]a2 option
    incr i 2
    binary scan $dhcp_option_payload x[expr $i]a2 length_hex
    set length [expr 0x$length_hex]
}
if { $i < $option_length } {
    incr i -[expr { $length * 2 -2 }]
    binary scan $dhcp_option_payload x[expr $i]a2 length_hex
    set length [expr 0x$length_hex]
    incr i 2
    binary scan $dhcp_option_payload x[expr $i]a[expr { $length * 2 }] circuit_id
} else {
    drop
}
}

URI re-writing based on Load Balancing decision

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

Talk about a chicken and egg demonstration. Hearing the title, you might think I have it backwards. When making this kind of decision in an iRule, the URI is often used to help make the load balancing decision. In this case, it's just the opposite. In this example we're letting the BIG-IP make a load balancing decision, then going back and updating the URI based on that decision, before the request is sent to the servers. Very cool stuff!

when HTTP_REQUEST_SEND {
set uri [string tolower [clientside {HTTP::uri}]]
log local0. "[IP::client_addr]:[TCP::client_port]: selected server details: [LB::server] - \$uri: $uri"
if {[IP::addr [LB::server addr] equals 10.207.225.101] or [IP::addr [LB::server addr] equals 10.207.225.102] or [IP::addr [LB::server addr] equals 10.207.225.103] }{
    log local0. "[IP::client_addr]:[TCP::client_port]: matched server check for .3 or .4"
    switch -glob [HTTP::uri] {
      "*/gsfo/gsfopub*" {
        clientside {HTTP::uri "/Async/CMReceive.ashx"}
        log local0. "[IP::client_addr]:[TCP::client_port]: updated URI to /Async/CMReceive.ashx"
      }
      "*/era/erapub*" {
        clientside {HTTP::uri "/Async/ERAReceive.ashx"}
        log local0. "[IP::client_addr]:[TCP::client_port]: updated URI to /Async/ERAReceive.ashx"
      }
      default {
        log local0. "[IP::client_addr]:[TCP::client_port]: didn't match URI checks"
      }
    }
}
}

There you have it, the forums deliver yet again. I have to say I love checking out all these cool, new, compact examples of iRules goodness. Many thanks to the awesome DevCentral community for their continued contributions. I'll see you next week for another 20 Lines or Less.

Technorati Tags: DevCentral,20 Lines or Less,iRules,DHCP,URI Rewriting,SSL Information,Colin Walker

#Colin

Taco Tuesday with Jason Hoffman, Joyent CTO

Colin Walker — Wed, 23 Jul 2008 19:09:39 GMT

So it looks like Joe and I are going to have to take a trip down to San Fran to check out Nick's Crispy Tacos with Jason Hoffman, CTO and co-founder of Joyent. Jason puts on a "Taco Tuesday" on the third Tuesday of just about every month. We've been invited down to check it out and geek out over the hawesome iRules/iControl/Ruby/*Nix/geeky stuff they're doing. Yeah...I'm not completely geeking out and excited, honest. Don't worry though, we'll try to make the best of it.

We got a fantastic opportunity today to talk with Jason about Joyent, what they're doing, their architecture, their background, etc. and how they're heavily leveraging F5 technology to make it all happen. For those of you that don't know, Joyent is a long-time F5 customer that provides a wickedly cool, scalable, flexible cloud infrastructure to users ranging anywhere from the Mom and Pop size to truly robust Enterprise level applications. You may have seen Joe's blog post about Joyent hosting LinkedIn's BumperSticker Facebook app that recently surpassed a billion page views per month. That spurred an offer to chat, and Jason was more than happy to oblige.

It was absolutely fantastic to talk to Jason who himself is an avid engineer that's got a long history with Unix and many of the flavors of coding that go along with it. As one of the first major adopters of Ruby and, in fact, the very first person to check in source to the Rails source control system, he definitely knows what he's talking about when it comes to *Nix programming, Ruby, and RoR. It turns out we even share a common love for and history with FreeBSD, go figure.

Over the course of our discussion we got to chat with Jason about his role at Joyent, what they're delivering to users, why it's unique and powerful, obstacles they faced along they way, how they got around them which, I'm happy to say, largely included F5 technology and specifically iRules and iControl, and many other such things impressively full of win. From many of their security policies relying on iRules instead of FireWalls, to iControl being an integral part of their provisioning system, to building iRules as solutions to countless customer problems or requirements, these guys are definitely power users and avid DevCentral members, I'm happy to say.

We also got to talk about the modern application, how it's architected, how the old school ways of thinking don't apply anymore and the massive benefits that can come from allowing yourself to see the possibilities with a modern, flexible, layered architecture. This architecture with powerful caches, application aware network devices serving large portions of the application functionality, and scalable, interchangeable back ends thanks to the load balancing that also occurs at that tier is hugely powerful and really more and more of a "must have" as things continue to progress in the application and application delivery world. Pretty darn cool stuff to hear from a PhD helping to run a hugely popular and successful hosting company. How's that for real world application?

This is the exact message I (we) have been pushing for a long time. Every time I talk about "preaching the good word", this is what I'm talking about. Times have changed, technology has improved, and F5 can be a big part of building a powerful, flexible, scalable, reliable architecture if you just let yourself think about things in the new, more modern world that Jason and Joyent have fully embraced. It's allowing them to be as powerful and usable as they are at extremely reasonable costs with incredible scalability as needed.

Check out the podcast to get more of the details. Obviously I'm excited, and am currently trying to refrain from a big squeeeee of geekitude, but that's just how I get when I get to riff about awesome technology with even more awesome people.

Stay tuned for the follow up where Joe and I tear into some tacos, margaritas and hopefully some iControl/Ruby/iRules with Jason down in his neck of the woods. Not that it's been approved yet or anything, but hey, I can hope, right?

Thanks again Jason for the great chat, and keep up the killer work.

Technorati Tags: DevCentral,iRules,iControl,Ruby,iContRuby,LinkedIn,FaceBook,BumperSticker,Joyent,Jason Hoffman,Colin Walker

#Colin

20 Lines or Less #11

Colin Walker — Thu, 17 Jul 2008 00:08:58 GMT

This week's 20LoL comes care of both the codeshare and the forums alike. I got to deal with a couple of particularly cool forum posts this week, one of which made the list, as did an iRule from the infamous hoolio himself. Dealing with HTTP and ranging from spiders to working around a work-week, these examples are yet more ways you can leverage iRules in less than 21 lines. Here we go:

Rate Limiting Search Spiders

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

Spiders on the web aren't the same pests as spiders in your house, but they can certainly have adverse effects if they're making an inordinate number of requests to your web-servers, and driving the load up. Here's a cool example of how to avoid just that scenario. We've seen something similar a long time ago on DevCentral for Network Computing, but this is a good refresher.

when RULE_INIT {
array set ::active_crawlers { }
set ::min_interval 1
}

when HTTP_REQUEST {
set user_agent [string tolower [HTTP::header "User-Agent"]]
# Logic only relevant for crawler user agents
if { [matchclass $user_agent contains $::Crawlers] } {
    # Throttle crawlers.
    set curr_time [clock seconds]
    if { [info exists ::active_crawlers($user_agent)] } {
      if { [ $::active_crawlers($user_agent) < $curr_time ] } {
        set ::active_crawlers($user_agent) [expr {$curr_time + $::min_interval}]
      } else {
        reject
      }
    } else {
      set ::active_crawlers($user_agent) [expr {$curr_time + $::min_interval}]
    }
}
}

Compression During the Work Week

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

Coming through with a great example of how to have compression enabled only from 8AM-5PM, otherwise known as the normal US Workday, citizen_elah shows of his iRules kung fooery to help a fellow community member out. This same logic could be applied to almost anything else, besides compression, making this a great iRule to keep around in your back pocket.

when CLIENT_ACCEPTED {    
  set time_r [split [clock format [clock seconds] -format {%k:%M} ] " "]  
  set time_f [expr {[expr {[lindex $time_r 0]*100}] + [lindex $time_r 1]}]     
  if { not(($time_f >= 800) && ($time_f <= 1700)) } {     
    set compression "off"    
  }    
}    
        
when HTTP_RESPONSE {     
  if { $compression eq "off" } {    
    COMPRESS::disable     
  }     
}

I then came through and offered some optional optimization, so I guess this could be considered your bonus-rule for the week. It's easy when someone like elah does the legwork up front. ;) Check the link to see the extra example.

Fully Decode URI

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

Representing the last leg of this HTTP tri-ath-a-post is an entry from our illustrious iRules CodeShare. This example shows how to be sure you're FULLY decoding your URI before processing. It correctly points out that sometimes encoded characters can contain encoded characters can contain encoded characters can contain....well, you get the point. See how one person decided to work around such issues in a scant 11 lines of code.

when HTTP_REQUEST {
  # decode original URI.
  set tmpUri [HTTP::uri]
  set uri [URI::decode $tmpUri]

  # repeat decoding until the decoded version equals the previous value.
  while { $uri ne $tmpUri } {
    set tmpUri $uri
    set uri [URI::decode $tmpUri]
  }
  HTTP::uri $uri

  log local0. "Original URI: [HTTP::uri]"
  log local0. "Fully decoded URI: $uri"
}

There you have it, three more choice examples of iRules goodness in 20 Lines or Less. Tune in again next week!

Technorati Tags: DevCentral,20 Lines or Less,HTTP,Colin Walker

#Colin

20 Lines or Less #10

Colin Walker — Thu, 26 Jun 2008 20:58:50 GMT

With another three examples of cool iRules, this week's 20 Lines or Less shows even more things you can do in less than 21 lines of code. I still haven't heard much from you guys as to the kinds of things you want to see, so make sure to get those requests in. I can build all sorts of neat iRules if you just let me know what would be helpful or interesting. Otherwise I might just make iRules that make iRules. Scary.

This week we've got a couple forum examples and a contribution to the codeshare. Here's your epic, 10th edition of the 20LoL:

HTTP Headers in the HTTP Response

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

Dealing with HTTP headers is one of the most common tasks we see in iRules. One of the things that I've seen floating about the forums and elsewhere lately is the question of how to access that information in the Response portion of the HTTP transaction. Some people have had a problem with this, as many of those headers no longer exist (like, say, the host). It's a simple solution though, as you can see below...just use a variable to get you there.

when HTTP_REQUEST {
# Save the URI
set uri [HTTP::uri]
}
when HTTP_RESPONSE {
if {([HTTP::header Cache-Control] eq "private, max-age=3600") and ($uri ends_with “.html”)} {
HTTP::header replace Cache-Control "public, max-age=3600"
}
}

Persistence equality in RDP sessions

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

This example solves an issue with mixing Linux and Windows based RDP sessions across a persistence enabled virtual Apparently there's an issue with trying to persist based off of the user string as some clients include user@local.host and others just include the username. That's a bit of an issue. iRules to the rescue, as always.

when CLIENT_ACCEPTED {
TCP::collect
}

when CLIENT_DATA {
TCP::collect 25
binary scan [TCP::payload] x11a* msrdp
if { [string equal -nocase -length 17 $msrdp "cookie: mstshash="] } {
    set msrdp [string range $msrdp 17 end]
    set len [string first "\n" $msrdp]
    if { $len == -1 } { TCP::collect }
    if { $msrdp contains "@" } {
      if { $len > 5 } {
        incr len -1
        persist uie [getfield $msrdp "@" 1] 10800
      }
    } else { persist uie $msrdp 10800 }
}
TCP::release
}

Pool Selection based on File Extension

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

Taking a page from the codeshare, this iRule lets you build a correlation of file extensions and pools that serve those particular file types. This can be quite handy when dealing with large scale image servers, media systems, and especially systems that do things like dynamically generate watermarks on images and the like. Take a peek.

when HTTP_REQUEST {
  switch -glob [HTTP::path] {
    "*.jpg"        -
    "*.gif"        -
    "*.png"        { pool image_pool }
    "*.pdf"        { pool pdf_pool }
    default        { pool web_pool }
  }
}

There you have it; three more examples in less than 60 lines of code. I hope you're still finding this series helpful. As always, feel free to drop me a line for feedback or suggestions. Thanks!

Technorati Tags: DevCentral,iRules,20 Lines or Less,Persistence,HTTP Headers,Colin Walker

#Colin

20 Lines or Less #9

Colin Walker — Thu, 19 Jun 2008 18:57:25 GMT

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

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

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.

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

   and (not ([IP::addr [IP::client_addr]/8 equals 10.0.0.0]))} {
      HTTP::redirect "http://google.com"
   }
}

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.

when CLIENT_DATA {
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

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

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.

Technorati Tags: DevCentral,iRules,20 Lines or Less,Cookies,Redirects,Syslog,UDP,HTTP,Colin Walker

#Colin