A friend of mine who also happens to be a BIG-IP user (yes, I have friends who are not BIG-IP users for those keeping score) hit me up on Skype recently to inquire about a problem he was facing with his Blackboard installation. He was seeing thousands of connections which was causing his servers to crawl. After looking into it a little, he found that the preview feature in the browsers was the main culprit for all the extraneous connections. Students hit Blackboard frequently as part of their daily life,  so it makes perfect sense that site would be high on the list for the preview tab. For those who are still on IE6 (shame on you!) or very early versions of other browsers who may not be in the know yet, the preview tab in the browsers pre-loads a number of your frequent or favorite sites giving you a quick launch tab for point of entry. Great for the user, not always so great for the site providers carrying that extra traffic that may not ever result in a page view. Here's an example:

browser_preview

So I spend a little time on DevCentral...

Anyway, now that the problem is identified, how to solve it? Well, there are many solutions one can take. With the Blackboard app specifically, you can include a rewrite rule in the web config file, and there are header link options as well to return a preview icon (not supported by all the browsers). Me? I'll go with an iRule, and not just because they're cool and I love them. My BIG-IP is the front door to all applications, so rather than sift through all the applications and determine the necessary point solution for them, I can drop one simple iRule at the front door and be done. From the information I uncovered, Opera, Chrome, and Safari all use the X-Purpose: preview header and Firefox uses the X-moz: prefetch header. The iRule is incredibly simple:

when HTTP_REQUEST {
  if { [HTTP::header exists "X-Purpose"] && ([HTTP::header "X-Purpose"] eq "preview") } {
    HTTP::redirect "/preview.htm"
  } elseif { [HTTP::header exists "X-moz"] && ([HTTP::header "X-moz"] eq "prefetch") } {
      HTTP::redirect "/preview.htm"
  }
}

This gives you--the site admin--control over the process. You could even host that preview.htm page in an iFile on the BIG-IP and keep the load off all your servers altogether. In fact, you could have some real fun that way, similar to the 404 Fun with iRules using Haiku responses.

 

 

 

 

Comments on this Article
Comment made 02-Apr-2014 by TDCornwell 0
I am quite new to F5, but doesn't the above suggested iRule create a redirect loop?

If not, why not?

Thanks!
-T
0
Comment made 02-Apr-2014 by Jason Rahm
Nope, this iRule is in production for a friend of mine. If neither of those headers exist and if they do exist but the values don't match, then the request just passes through the event logic unscathed. If they do match both conditions, the requests are redirected to the preview page, but a request for the preview page will not match this logic, so the iRule won't cause a loop.
0