Forum Discussion
Bob_10976
Nimbostratus
NimbostratusSelect Pool on URI causing Infinite loop..
Hello all..With the help of this group i've got an irule that will use a specific pool based on the URI path, which I've listed below. However it appears that is causing an infinite loop. I wasn't aware at the time that it would be a different URL at the time, but now I'm being told now the path could something like /shopping/SomeGUID/admin or /shopping/SomeGUID/Shipping or host of other URIs where the GUID changes. I changed the path to match one of the GUIDs and it worked, but as I mentioned I don't know what the GUIDs will be ahead of time. I did some searching through the forums and found some info on wildcards so I tried /shopping/* and you can see below I have /shopping* but still no joy.
Any thoughts or suggestions on to make this work so no matter what the URI is after "/shopping" it will always use the secure2.mydomain.com pool?
when HTTP_REQUEST {
switch -glob "[string tolower [HTTP::path]]" {
"/shopping*" -
"/path2*" {
pool secure2.mydomain.com
}
default {
pool secure.mydomain.com
}
}
}
Thanks,
Bob
- If you want to ensure that any request that comes in to mydomain.com/shopping/...anything ... gets sent to a pool named secure2.mydomain.com (which is an odd pool name) then your rule should work fine. If, more likely, you're trying to do an HTTP redirect to a website named secure2.mydomain.com, then you'd need to change the code a bit to use the right command.
Are you trying to direct traffic to a specific pool, or a specific domain name (by issuing a redirect)?
Colin 
Bob_10976I'm trying to direct traffic to a specific pool, our W2K8 server pool, when an end user goes to https://mydomain.com/shopping/EndUserStore/cart it works, however when an enduser attempts to go to https://mydomain/shopping/enduserstore/admin it starts an endless loop. I believe this has something to do with our single sign on process. If the end users goes to the admin area of their store they are required to log in, I get to the log in page but after logging in is when the loop happens when its trying to go back from the single sign on page to the /shopping/enduserstore/admin path. The "enduserstore" is a GUID that is different for each endusers store, so I don't know what that GUID will be.
Also just a quick note, the pool name is the same name as the VIP, just makes it easier to match up what Pools go with what VIPs.
Thanks,
Bob
Michael_YatesMy guess is that it is not your iRule that is causing your redirect loop.
It sounds like the iRule is working as intended, but the application server is not liking something about the incoming request so it is trying to redirect you somewhere else (your suspected single sign on process maybe?).
There are several ways that you could verify this. But the easiest may be something in the HTTP_RESPONSE Event to log the server response and status code.- Bob_10976Thanks Michael, that sounds about like what the problem could be, at the single sign on process. I looked at the Wiki for the Http response, but i'm not sure I follow it completely. I'm not sure which type of response i'm getting so i'm not sure what to request it agaist. is there a generic/catch all I should start with to help narrow it down?
Thanks,
Bob - The_BhattmanHi Bob,
You could use
log local0. "The Full URL and path is : [HTTP::host]/[HTTP::uri]"
In your iRule to log the entries to determine what is being requested
I hope this helps,
Bhattman
