Forum Discussion

Wes_98712's avatar
Wes_98712
Icon for Nimbostratus rankNimbostratus
Nov 13, 2006

JSession and SSL Session Persistence

I've been researching the most optimal persistence methods when it comes to JSessionID's specifically because in a non-clustered/non-replicated implementation of a servlet container the SessionID is used to persist the client to a specific node. There is a ton of good information on this site about finding and using the jsessionID to persist a client connection using the universal inspection engine, and I have found that it works great, in fact I've reused some of it as follows:

 

 

when CLIENT_ACCEPTED { 
      set add_persist 1 
      set retries 0
} 
when SERVER_CONNECTED {
   log local0. "Node IP address: [IP::server_addr]"
}
when LB_SELECTED {
  Should only be called if we encounter an HTTP 5XX error
  and we don't want to create a loop so I'm trying to only check for it once.
  if {$retries >= 1} {
    LB::reselect pool www_web_prd_pool
  }
}
when HTTP_REQUEST { 
   if { [HTTP::cookie exists "JSESSIONID"] } { 
      persist uie [HTTP::cookie "JSESSIONID"] 
      log local0. "HTTP Request SessionID = [HTTP::cookie "JSESSIONID"]"
   } else { 
      set jsess [findstr [HTTP::uri] "jsessionid" 11 ";"] 
      log local0. "HTTP Request jsess var = $jsess"
      if { $jsess != "" } { 
         persist uie $jsess 
      } 
   } 
}
when HTTP_RESPONSE { 
   Looking for invalid response codes.
   if { $my_httprcode starts_with "5" and $retries <= 1 } {
      log local0. "HTTP RESPONSE CODE = $my_httprcode"
      incr retries
      log local0. "retry number $retries"
      HTTP::retry $my_httprequest
   }       
   if { [HTTP::cookie exists "JSESSIONID"] and $add_persist } { 
      log local0. "HTTP Response SessionID = [HTTP::cookie "JSESSIONID"]"
      persist add uie [HTTP::cookie "JSESSIONID"] 
      set add_persist 0 
   } 
}

 

 

Now when we start talking about SSL, rather than relying on standard client affinity or cookie insert with a timeout value (risk here is if the session is crap the client will continue to persist, when there could be another server available that works), what I would like to do is one of two things:

 

 

1. Persist based on the SSL SessionID

 

2. Persist based on the JSessionID (tried this, with the above rule, and 50% of the time it bounces between nodes, probably due to the fact we are using SSL and not standard HTTP eh? 😉

 

 

Ideally I want something as follows:

 

 

when HTTP_REQUEST {
   if { [HTTP::Header exists "SessionID"] } {
      persist uie [HTTP::Header "SessionID"]
}

 

 

Before I get flamed, I know the above won't work, but I'm trying to provide some pseudo code to spark this chain.

 

 

If there is indeed a way to persist via the SSL SessionID, that would be fantastic. Though it begs me ask the question, would I want to do that? Especially if certian browsers force a refresh on an interval basis, not sure if IE still does this, but rather than risk that, and rather than risk persisting to a node that is failing, I want to force it via JSessionID or some other method.

 

 

Maybe active cookie insert is the way to go, but then check for an invalid HTTP response, down the node, and re-load balance the request?

5 Replies

  • Hi,

     

     

    i would strongly advise against SSL persistence.

     

     

    SSL persistence is base on the SSL SessionID. The thing is that IE for example (not sure for v7 but it's the case for the earlier versions) will renegociate this SessionID every 2 minutes i.e you'll be load balanced again ><

     

     

  • SSL Session persistence is not a solution, the issue with new SSL requests which generate a new SSL SessionID is valid.

     

     

    The real solution is to base persistence on the JSessionID (for java apps) or php sessionID or whatever cookie is being set.

     

     

    I was actually able to persist users across 2 different VIP's (one HTTP and one SSL) using the JSessionID in a cookie hash profile and matching that across virtuals. So long as the pool members in each VIP are the same this will work. If they are not it won't work. If they are not than the user will hit 2 different servers one for HTTP and one for HTTPS.

     

     

    In a clustered environment where true session replication is working, persistence is a really stupid thing to use. No offense to anyone. But in reality so long as the F5 can understand who the primary and secondary cluster replicates are it should be able to load balance to them, if the first goes down it knows who has the session.

     

     

    mod_jk and proxy plug-in's like weblogic and websphere have this ability built in, which is why many folks choose to use them, however, based on personal experience with the mod_jk it cannot handle extreme load, it ends up bogging down the server. The weblogic proxy-plugin is exteremly efficient...go figure.

     

     

    At any rate, I digress. If there is a reason to persist to SSL sessions, I would highly suggest offloading SSL to the F5, using server side SSL (if the app requires SSL to run on the servers) and then use a simple Cookie persistence profile that looks for the applications cookie, not the SSL SessionID.

     

     

    -Wes