Forum Discussion
dubdub
Jun 15, 2011Nimbostratus
iRule to intercept traffic and then send on to original pool
Hi all,
I refuse to believe this is impossible, so I just need some advice on how to make it happen!
I am trying to create an iRule to intercept certain requests for additional processing before ultimately sending them on to their original target. The main application server tier is a data warehouse application. Users of the data warehouse app must be in a specific AD security group in order to access it. A separate web application (on a completely different environment) has been created that will handle this group processing - it will check if the user is already in the security group, and if not, it will add them. Once the user has established a session with the data warehouse, I can bypass sending any requests to the web application because I'll know that user has already been added. The session can be verified by looking for the jsessionid value.
So, this is the general flow I need:
if the jsessionid exists {
send to original pool, no special handling required
} else {
if the pool for the web application is up {
preserve the original URL somehow
invoke the web application
} else {
send to the original pool; the user may already be a member of the group and have access - we don't want to prevent them getting through just because the web app may be unavailable
}
}
I've tried a number of combinations of HTTP headers, cookies, redirects, responds, etc. in an attempt to get the intercept working. It seems that getting the flow back from the web application and sent onto the data warehouse within the same connection is not likely to happen, so I was hoping to send the original URL along to the web app, and have the web app actually do the redirection to the original data warehouse URL. However, the URLs can be unbelievably long, and I could seriously run into the URL limit boundary if I try to pass the original URL as a query parameter to the web application. I tried passing the URL as an HTTP header and as a cookie - neither seems to survive its transit into the web app (where right now we are dumping all header variables, cookies, etc. to the browser just as a gut check).
Any other suggestions on how I can get this URL down to the web app? Or is there a completely better way to approach this?
Thanks,
Jen
- hooleylistCirrostratusHi Jen,
- dubdubNimbostratusHi Aaron,
- dubdubNimbostratusJust to follow up... finally got this working, this is the final iRule, which is a variation on the excellent ideas suggested in http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/14001/showtab/groupforums/Default.aspx.
- hooleylistCirrostratusNice work in figuring that out. Thanks for posting your rule.
- JRahmAdminJust a note on optimizations...I was curious about the efficiency of $static::debug != 0 versus $static::debug == 1 versus just $static::debug...here's how it worked out in my testing:
1. 37166 cycles on average over 5000 requests from (ab -n 5000 -c 25 http://172.16.101.85/) if { $static::debug != 0 } {} 2. 34341 cycles on average over 5000 requests from (ab -n 5000 -c 25 http://172.16.101.85/) if { $static::debug == 1 } {} 3. 29034 cycles on average over 5000 requests from (ab -n 5000 -c 25 http://172.16.101.85/): if { $static::debug } {}
A 21.9% savings by using the 3rd option as opposed to the 1st!
- hooleylistCirrostratusThe last one is the simplest, but it's great to hear that it's also the most efficient. Thanks for testing this.
Recent Discussions
Related Content
Â
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects