F5 HTTPS Redirect iRule Update
F5's old _sys_https_redirect iRule is simple, and gets the job done, but it's starting to show its age. It has some issues handling today's web apps: It always sends a 302 redirect. This changes POST requests to GET, breaking things like form submissions. We should use a 308 instead to preserve the request method. It chokes on IPv6 host headers. If you have an IPv6 address like [2001:db8::1]:8080, the getfield command used to parse out the host will fail. We need a smarter way to handle that. There's no way to make exceptions. Sometimes you need HTTP for things like Let's Encrypt validation or health checks. The iRule redirects everything to HTTPS unconditionally. It doesn't set any security headers. The redirect response is bare-bones. It's a missed chance to enable some extra protections. Everything is hardcoded. Want to change something? There are no editable parameters. Not the most admin-friendly. Zero visibility. If something isn't working right, good luck figuring out why. The iRule doesn't log anything for troubleshooting.BIG-IP Solutions: Simple URL Redirects
Check out our "BIG-IP Solutions" series where we will dive into all kinds of cool features related to the BIG-IP. In this edition, I'll take a look at simple URL redirects where I'll show how to redirect traffic from one web page to another. Many people use iRules for URL redirects, but the BIG-IP offers policies to do this for you. Policies are faster than iRules, they are easier to manage, and you don't have to know the exact scripting language code to use them. Check out this video to learn more about how to redirect URLs with policies!Post of the Week: HTTP Redirect using Datagroups
In this "Post of the Week" video, we discuss HTTP redirects and how to use datagroups and iRules to do these redirects. If you have lots of URLs to redirect, then you might want to consider using something like this. Enjoy! Resources Developing iRules for BIG-IP
20 Lines or Less #43 – Nesting, Rewriting Redirects and Auth
What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week for the devcentral community, 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. In the first 20LoL of the new year I bring to you a diverse offering of iRule goodness ranging from HTTP Authentication via iRule, to nesting switch inside if and why it’s important not to use elseif when doing so, as well as re-writing partial URL strings for redirection. Nesting switch inside if http://devcentral.f5.com/s/Community/GroupDetails/tabid/1082223/asg/50/afv/topic/aft/1176698/aff/5/showtab/groupforums/Default.aspx It earns cool points, in my opinion, to use logic in cool ways like this. The big caveat to keep in mind though is something that user TMaCEvans ran into, elseif. If you’re adding a switch statement inside your if logic keep in mind that the switch statement itself isn’t a valid comparison for the elseif operator. This means you’ll need to use a simple else and put the switch inside there with whatever appropriate logic you need, as Chris Miller pointed out in his helpful response containing this example: when HTTP_REQUEST { if { [string tolower [HTTP::path]] starts_with "/xyz/" or [string tolower [HTTP::query]] contains "xy=9" } { if { [HTTP::method] eq "GET" and [HTTP::header "Upgrade"] contains "WebSocket" } { HTTP::disable pool pool3 } pool pool3 } else { switch -glob [string tolower [HTTP::uri]] { "/fr/app*" { pool pool2 } default { pool pool1 } } } } URI Re-writing for redirection http://devcentral.f5.com/s/Community/GroupDetails/tabid/1082223/asg/50/afv/topic/aft/1176697/aff/5/showtab/groupforums/Default.aspx#1201401 User ukitsysadmin has been asking about how to take a part (the end) of an existing URI and use that as the key for a class lookup to find the new URI he wants to redirect users to. This is very doable and Aaron knocked out the more complex string parsing logic. I came in to finish up with a little class search/findclass goodness. I’m listing the v10 version of the example, even though it turned out ukitsysadmin is on 9.4.7. I just think class match is sexier than findclass. when HTTP_REQUEST { set uri_token [string range [HTTP::path] [expr {[string last / [HTTP::path]] + 1}] end] } when HTTP_RESPONSE { if {[HTTP::status] == 404} { set red_uri [class match -value $uri_token equals class_name] HTTP::redirect $red_uri } } HTTP Basic Auth via iRules http://devcentral.f5.com/s/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1086387/HTTP-Basic-Access-Authentication-iRule-Style.aspx While digging through the forums I came across this post which talks about HTTP auth via an iRule. As Jason was kind enough to point out, George wrote this up in a Tech Tip a while back that showed how to do this clearly and to great effect. I figured I’d link to the full article as well as the post for clarity. This is a very cool technique that I can’t remember if I’ve highlighted here or not (130+ 20LoL code examples later…things tend to blend together), so I’m adding it here because it’s slick and can potentially be very handy. when HTTP_REQUEST { binary scan [md5 [HTTP::password]] H* password if { [class lookup [HTTP::username] $::authorized_users] equals $password } { log local0. "User [HTTP::username] has been authorized to access virtual server [virtual name]" # Insert iRule-based application code here if necessary } else { if { [string length [HTTP::password]] != 0 } { log local0. "User [HTTP::username] has been denied access to virtual server [virtual name]" } HTTP::respond 401 WWW-Authenticate "Basic realm=\"Secured Area\"" } } There you have it, some more cool iRule examples to remind you just how powerful this stuff can be in less than 21 lines of code. Pass it one, send some feedback, make some requests to let me know what you’d like to see next time, and I’ll be back with more as always. #Colin
Automatically detecting client speed
We used to spend a lot of cycles worrying about detecting user agents (i.e. browser) and redirecting clients to the pages written specifically for that browser. You know, back when browser incompatibility was a way of life. Yesterday. Compatibility is still an issue, but most web developers are either using third-party JavaScript libraries to handle detection and incompatibility issues or don't use those particular features that cause problems. One thing still seen at times, however, is the "choose high bandwidth or low bandwidth" entry pages, particularly on sites laden with streaming video and audio, whose playback is highly sensitive to the effects of jitter and thus need a fatter pipe over which to stream. Web site designers necessarily include the "choose your speed" page because they can't reliably determine client speed. Invariably, some user on a poor connection is going to choose high bandwidth anyway, and then e-mail or call to complain about poor service. Because that's how people are. So obviously we still have a need to detect client speed, but the code and method of doing so in the web application would be prohibitively complex and consume time and resources better spent elsewhere. But we'd still like to direct the client to the appropriate page without asking, because we're nice that way - or more likely we just want to avoid the phone call later. That would be a huge motivator for me, but I'm like that. I hate phones. Whatever the reason, detecting client speed is valuable for directing users to appropriate content as well as providing other functionality, such as compression. Compression is itself a resource consuming function and applying compression in some situations can actually degrade performance, effectively negating the improvement in response time gained by decreasing the size of the data to be transferred. If you've got an intelligent application delivery platform in place, you can automatically determine client speed and direct requests based on that speed without needing to ask the client for input. Using iRules, just grab the round-trip time (or bandwidth) and rewrite the URI accordingly: when HTTP_REQUEST { if { [TCP::rtt] >= 1000 } { HTTP::uri "/slowsite.html" } } If you don't want to automatically direct the client, you could use this information to add a message to your normal "choose your bandwidth" page that lets the client know their connection isn't so great and perhaps they should choose the lower-bandwidth option. This is also good for collecting statistics, if you're interested, on the types of connections your customers and users are on. This can help you make a decision regarding whether you even need that choice page, and maybe lead to only supporting one option - making the development and maintenance of your site and video/audio all that much more streamlined.
