Persistence Cookie iRule not working as desired

O.K. I have not tested it, so you'll have to do it the other way round :-)) Sorry for that.

Can you please try this?

when HTTP_REQUEST {

persist none

 all the other stuff

if { [HTTP::path] equals "/api/v1/sendpinajax" } {
log local0. "[IP::client_addr]:[TCP::client_port]: this is the path [HTTP::path] "
HTTP::respond 200 content "HTTP path [HTTP::path]\n\n"
HTTP::path /sendpinajax
pool MM-MEP
persist cookie insert "MM-MEP-SENDPIN"
}
} 

BTW: do you know if the clients are using HTTP 1.1?

i understand persistence profile is required when using persist cookie command.

 

 

by the way, i agree with Kurt's irule, i.e. setting persist none first and then specifying custom persist cookie on specific url, since your irule does not set persist none on url which does not match those conditions.

 

 

additionally, utilizing if/elseif instead of series of if clause would be good.

 

 

e.g.

 

 

if {...} {

 

do something

 

} elseif {...} {

 

do something

 

} elseif {...} {

 

do something

 

} else {

 

do something

 

}

Guys thanks for all the help. I will use persist none in for the urls where I do not need persistence and default persistence profile for urls where i need persistence. I am doing this because I am sure in future we will have urls wich will select new pool members and the KB article which I pasted above talks about this limitation , that if we have an iRule which selects differnt pools with non similar pool members, persistence fails unless we have default cookie name.

 

 

Also as Kurt mentioned if the same TCP session is used to do a Get requet for a new url persitence will not work as desired because it is based on sessions. I noticed that while testing from my browser, so when I was jumping from one url which had persistence to one which did not have, I was not getting right pool member until i hit rtefreshed once or twice, which I guess in the back opens a new TCP socket and the persistence selection logic kicks in.

 

 

Thanks again.

Also as Kurt mentioned if the same TCP session is used to do a Get requet for a new url persitence will not work as desired because it is based on sessions. I noticed that while testing from my browser, so when I was jumping from one url which had persistence to one which did not have, I was not getting right pool member until i hit rtefreshed once or twice, which I guess in the back opens a new TCP socket and the persistence selection logic kicks in. if i'm not wrong, Kurt may want to mention this sol.

 

 

sol7964: Persistence may fail for subsequent requests on Keep-Alive connections

 

http://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html

nitass.. :) I tried oneconnect on my profile and I like it ..It solves the problem when I am changing urls w/o closing browser which have different persistence behavior according to the iRule