Forum Discussion
Frank_J_104756
Sep 24, 2007Historic F5 Account
irule feature question
Site has multiple VS, A, B, C, D...user 1 comes in and gets directed to VS A. VS A has coookie insert persistence. User gets a cookie. Something on the user side (AOL proxy) changes and user then g...
Frank_J_104756
Sep 26, 2007Historic F5 Account
I"m starting to see that my initial approach was a bit too simple then...What I'm going do to is make sure that each of the geographically distributed stand-alone LTM's have "all" pools...both the one's local to it and the pools local to the other...from what you're saying my idea of
if { [HTTP::cookie exists "Cookie name"] }{
pool poolname (where poolname is the name of the pool that was assigned to the first VS when the user was issued the cookie)
would be too simple...my thought was since the user would be in the middle of a shopping session when they changed proxies, got a new A record pointing to a new VS..I thought it'd be more complicated setting the irule up to point them back to the original VS. Plus I'd also have to change the host to map specifically to that VS - ie ww1, ww2, ww3, etc...then I'd have to use a stream profile to rewrite the generic www.sitename.com the app is giving out to ww1.sitename.com to insure the client would continue to return to that VS. As you pointed out earlier, that kind of static redirection has some flaws.
so with the scenario: user shopping off of VS1A (box 1 VS A)...then AOL switches them to another proxy which does a new lookup. Now in the middle of their shopping, with a "cart" full of items, they're redirected to VS2A (box 2 VS A). The web / app servers referenced by this VS have no knowledge of what was done on VS1A.
to get around this, my thought was, don't mess with the VS at all. If their going to bounce around between proxies that's fine...I'll use the cookie they got when they hit the VS1A initially to cause VS2A to send them to the default pool that VS1A was using. By doing this, I'd hoped to avoid them getting a new cookie, or seeing any interruption in their shopping. With that in mind, will the logic below work ? The VS would still have it's default pool so if they don't have a cookie - ie new user - then they'll get the cookie from the VS/Pool the A record sent them to and the logic would still apply...they'll continue to go to that pool
if { [HTTP::cookie exists "Cookie_for_pool_VS1A"] }{
pool VS1A
}
if { [HTTP::cookie exists "Cookie_for_pool_VS2A"] }{
pool VS2A
}
etc...
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