JSessionID URI Persist

You're right, since findstr doesn't find your jsessionid, it returns everything

matches_regex is CPU expensive it may be best to try something like this:

 
   
  when HTTP_REQUEST {     
    if { ([HTTP::uri] contains "/mosAppWar") and ([HTTP::uri] contains "jsessionid") } {     
        set jsess [findstr [HTTP::uri] "jsessionid" 11 ";"]     
        if { $jsess ne "" } {     
          log local0. "creating persistency with $jsess"  
           persist uie $jsess     
        }  
        pool Application_Pool     
        log local0. "QA2 Server: [LB::server addr] jsessionid $jsess Query: [HTTP::uri][HTTP::query]"     
        return      
      } else {     
        pool Static_Pool     
        return     
       }     
   }    
 

As nmenant pointed out, the jsessionid isn't always terminated in the URI with the same character. Even within the same session, there are slight variations with the "." ending. It should fine using . as the terminator.

 

 

It looks like there might be a bug in the application's links. This URI isn't standard for java-based applications. The jsessionid should be followed by a question mark with pgSourceofBusSearch_btProceed=loadtarget being part of the query string.

 

 

This URI:

 

/mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0pgSourceofBusSearch_btProceed=loadtarget

 

 

looks like it's missing the ?:

 

 

/mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0?pgSourceofBusSearch_btProceed=loadtarget

 

 

If you fix that issue, as an alternative, you could change HTTP::uri to HTTP::path and not use a terminator for findstr at all. HTTP::path is the URI minus the ? and anything after it if it's present in the URI.

 

 

Also, if the findstr output is empty, no persistence entry will be added. Finally, you can remove the return command as it's not going to make any difference as there isn't any code that would be executed from that point anyhow.

 

 

Aaron

For capturing the jsessionid I would suggest using HTTP::path instead of HTTP::uri

 

This will remove the URI query string for you (note: "?" denotes the start of query not ";").

 

 

Thus this statement should capture it correctly (it seems to behave on my systems)

 

set jsess [findstr [HTTP::path] "jsessionid" 11 ";"]

 

 

Rob.

HTTP::path is definitely a good solution to bypass the ? issue.

 

 

After i think "." will be enough since you'll miss only one digit in the jsessionid. But if you need to see the exact jsessionid you should definitely go for HTTP::path

Thank you for everything! I have confirmation that it is 99% working now.

Although I still have one more problem to tackle and it seems huge!

The problem is that the login page starts on one application and when you click submit you get sent to another. After that point persistence sticks and everything is ok.

Flow:

1. Surf to .com/mosAppWar/MosSystem/pgSignOn No JSessionID at this point which is the problem

2. Same page as 1. The JSessionID is assigned to a form post. Because of that the LTM only adds it to the UIE after post which is too late

[script removed]

Is there a method to parse the html on the way to the user in order to find the JSessionID? or is there a better way of going about this?

Thank you in advance,

Lance

Since the jsessionid must be contain in the response it should be possible to do it by parsing the response.

To do so, you can use HTTP::collect and HTTP::payload to be able to parse the response and activate the persistency on the first response of the web server

You have a example about how to use those commands here: Click here

Then once you have the payload you just need to extract the jsessionid and activate persistency

 
 when HTTP_RESPONSE { 
    trigger collection for up to 1MB of data 
   if {([HTTP::header exists "Content-Length"]) && ([HTTP::header "Content-Length"] <= 1000000)}{ 
     set content_length [HTTP::header "Content-Length"] 
   } else { 
       set content_length 1000000 
   } 
   if { info exists content_length } { 
     HTTP::collect $content_length 
   } 
 } 
 when HTTP_RESPONSE_DATA { 
  if {[HTTP::payload] contains "jsessionid"} { 
     set jsessionid [findstr [HTTP::payload] "jsessionid" 11 "."] 
     persist add uie $jsessionid 
   } 
 } 
  
 

One question:

 

 

Isn't it possible for you to use cookie persistence ? it would save an iRule which is always easier to maintain

In my case, we are required to support users who may block cookies, but the application sends the JSESSIONID cookie as well as the path information, so I build the table from the contents of the cookie, and reference the table only for users who don't support cookies. For those that do, we have the ltm cookie insert, so that for the majority of our traffic, the persistence is passive.

You make a great point. We started with Cookie Insert although we found that with two pools under the same VIP (application/static) the cookie was being messed up and it just round robined. We also tried SSL but all requests were stuck on the static pool (even the application requests!)

Did you have oneconnect enabled in that scenario?