Forum Discussion
Wes_98712
Nimbostratus
Nov 13, 2006JSession 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
- The_Bhattman
Nimbostratus
What about SSL Persistence? - Nicolas_Menant
Employee
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 >< - The_Bhattman
Nimbostratus
What about Firefox? or other browsers? - Nicolas_Menant
Employee
i don't remember firefox having the same behavior, it's only IE for me. - Wes_98712
Nimbostratus
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
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects
