Forum Discussion
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 gets directed to VS B. Can an irule be written and applied to VS A, B, C, and D that would recognize an F5 created cookie in the HTTP stream, and redirect the client back to the VS that originated the cookie ?
This is an ecommerce site and what is happening is costing a lot in money and customer satisfaction since the shopping cart doesn't stay populated.
Thanks!
16 Replies
- we needed logic to validate that the destination pool is actually up so the irule now looks like below...problem is that if that original pool is down and the user gets directed to the default pool of the VS they now have 2 cookies. If the original pool comes back up, they'll get sent to it and lose whatever shopping they've done on the default pool. Is there any way to remove the cookie from the original pool if it's down ?
when HTTP_REQUEST {
set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "]
if { $CookiePool !=""} {
if {[active_members $CookiePool] > 0} {
pool $CookiePool
log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool $CookiePool" }
else {
pool [LB::server pool]
log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool [LB::server pool] because original pool $CookiePool is down"
}
}
} - JRahm
Admin
when you've determined that the pool is no longer available, remove the cookie:
HTTP::cookie remove BIGipServer - it's not removing the cookie though
when HTTP_REQUEST {
set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "]
if { $CookiePool !=""} {
if {[active_members $CookiePool] > 0} {
pool $CookiePool
log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool $CookiePool" }
else {
pool [LB::server pool]
HTTP::cookie remove "BIGipServer$CookiePool"
log local0. "removing cookie BIGipServer$CookiePool. Remaining cookies are [HTTP::cookie names]"
log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool [LB::server pool] because original pool $CookiePool is down"
}
}
} - the irule shows the cookie gone, see output below, but the cookie still exists on the browser
Rule follow_the_cookie_to_the_pool : removing cookie BIGipServerf502_Web_Top_Pod_4. Remaining cookies are bmScrRes cookieID bmTzOff bmJava bmClrDpt JSESSIONID BIGipServerf502_Web_Top_Pod_5 cmRS - the site has expressed willingness to use non-session cookies if having expiration dates allows us to make this work.
- Here is the final working irule, until the customer asks me to change it agiain : )
when HTTP_REQUEST {
search cookies in http header for a bigip issued cookie
set CookiePool [findstr [HTTP::cookie names] "BIGipServer" 11 " "]
if bigip cookie is present AND pool it points at is active, then go to pool...maintians user shopping cart info. Log to local0.
if { $CookiePool !=""} {
if {[active_members $CookiePool] > 0} {
pool $CookiePool
log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool $CookiePool" }
else {
if original pool is down, use the default pool for the new VS...send the 302 to the user to expire out the cookie from the
original pool so that that the only cookie present is for the new pool. User will lose shopping cart from original pool.
log client ip, VS IP, and pool info to local0. for troubleshooting.
pool [LB::server pool]
HTTP::respond 302 Location "http://[HTTP::host]" "Set-Cookie" "BIGipServer$CookiePool=; path=/; Max-Age=0;"
log local0. "removing cookie BIGipServer$CookiePool. Remaining cookies are [HTTP::cookie names]"
log local0. "sending [IP::client_addr] coming in on [IP::local_addr] to pool [LB::server pool] because original pool $CookiePool is down"
}
}
else {
if no bigip cookie is present - ie new session, then use the default pool for the VS.
pool [LB::server pool]
}
}
