URI Session ID based persistence issue

I’ve come across a need for persistence based off a session ID imbedded in a URI, and unfortunately, I can not get it to work.

 

 

Here’s the lowdown – I need to persist users based upon a session ID found in the URI (source & cookie based persistence are not an option). Users will be jumping from http to https and back, and they need to be sent to the same pool member (Persist Across Services is enabled).

 

 

Here is the iRule I was testing with (it is applied to the http and https VS)

 

 

when HTTP_REQUEST {

 

set fletchpersist [findstr [HTTP::uri] "(X(1)S(" 7 ")"]

 

log local0. "fletchpersistvalue is $fletchpersist"

 

if { $fletchpersist != "" } {

 

persist uie $fletchpersist

 

} else {

 

pool fletch_mobiletest_0

 

}

 

}

 

 

 

The original user request comes in for http://www.mysite.com/

 

 

Then the webservice will determine the browser does not accept cookies, and send the user a redirect to http://www.mysite.com/(X(1)S(l00lky55541j11jofh04eyfl))/login.aspx

 

 

In this case ‘l00lky55541j11jofh04eyfl’ is the session ID, and since it sends this value to the log file via the log statement in the iRule, I assume it is identifying it correctly.

 

 

Once the user follows the redirect and hits the new URL above, he is sent another redirect to the same exact URL/URI, however its to the secure site at https://

 

 

Now, the user will be coming in via https (which is decrypted and re-encrypted so we can inspect the URI), and needs to be sent to the same pool member. Since the session ID is the same as in the previous unencrypted request, I would assume the UIE based persistence iRule would send the connection to the same server.

 

 

Wrong. The https connection is re-load balanced.

 

 

Here is what I observed…..

 

 

Even though the iRule will log the session ID no matter where in the session it comes, the BIG-IP will not enter the value into the persistence table unless it comes in the first http request. So since the first request is for http://www.mysite.com, nothing gets entered into the persistence table. The next request (which comes in the same TCP connection) is for http://www.mysite.com/(X(1)S(l00lky55541j11jofh04eyfl))/login.aspx, which has the value I need to persist off of.

 

 

However unless I force the initial http request to have that session ID in it (which will never happen ‘in the wild’), the session ID is not entered into the table, and the subsequent HTTPS connection (with the ID in the URI) gets re-load balanced.

 

 

Should the BIG-IP be entering the session ID into the persistence table even though it is not in the first request?

 

If not, anybody have a suggestion for getting the ID into the table?

 

 

Thanks in Advance!