JSESSIONID's with null or empty values

Apparently, the JSESSIONID is getting set to an empty string, so I don't necessarily need to check for null values.

Hi Chris,

 

 

The JSESSIONID codeshare example checks that the ID is not null, so you shouldn't have any persistence used or modified if the jsessionid is not set or is empty (whether in the request URI or cookie or response cookie).

 

 

Are you seeing an issue with this logic?

 

 

Aaron

Thanks for taking the time to respond. I believe that the issue I'm seeing is that the jsessionid is getting set to an empty string when the user clicks logout and the JSESSIONID rule on codeshare doesn't seem to know what to do when the Cookie exists but has no value. From my user's perspective, they see a 502 error.

Hi Chris,

 

 

The Codeshare example shouldn't be doing anything if the JSESSIONID cookie is not set or set to a null value. And the iRule cannot be sending an HTTP response of any kind.

 

 

I'd try testing this on a test VS with debug logging enabled. You could also try using Fiddler2 or a browser plugin which records the HTTP requests/responses to see what's happening.

 

 

Can you reproduce this issue if you disable all but one pool member for the test VS? How about if you test directly to a single server?

 

 

Aaron

As we speak, I'm trying to get that testing done because right now, the page I'm expecting to see, I am seeing but one of the two app servers is down. I'm waiting for the administrators of those servers to bring it back up so I can test some more. Will post an update soon.

OK. Let me correct myself here. I have 1 app server down right now. User clicks Signout, they get the error. I've also tried using an older jsessiondid persistence rule for testing as well:

when HTTP_REQUEST {

if { [HTTP::cookie exists "JSESSIONID"] } {

persist uie [HTTP::cookie "JSESSIONID"] 1800

} else {

set jsess [findstr [HTTP::uri] "JSESSIONID" 11 ";"]

if { $jsess != "" } {

persist uie $jsess 1800

}

}

}

when HTTP_RESPONSE {

if { [HTTP::cookie exists "JSESSIONID"] } {

persist add uie [HTTP::cookie "JSESSIONID"] 1800

}

}

This rule also fails. Someone who is much smarter than me in this area provided the following updates, which works for what we need it to do:

when HTTP_REQUEST {

if { [HTTP::cookie exists "JSESSIONID"] } {

set jsess [HTTP::cookie "JSESSIONID"]

if { $jsess != "" } {

persist uie $jsess 2700

}

} else {

set jsess [findstr [HTTP::uri] "JSESSIONID" 11 ";"]

if { $jsess != "" } {

persist uie $jsess 2700

}

}

}

when HTTP_RESPONSE {

if { [HTTP::cookie exists "JSESSIONID"] } {

set jsess [HTTP::cookie "JSESSIONID"]

if { $jsess != "" } {

persist uie $jsess 2700

}

}

}

Aaron, if you still have the time, can you help me understand what these changes are doing? I thought I understood but I guess I haven't fully grokked it.

Hi Chris,

I've updated your second example to streamline it a bit and add comments. The reason this approach works for null cookie values is that HTTP::cookie value "cookie_name" will return nothing if the cookie is not present or has a null value.

when HTTP_REQUEST {
    Check if the JSESSIONID cookie is present in the request and has a non-null value
   if { [HTTP::cookie "JSESSIONID"] ne "" }{
       Persist on the JSESSIONID cookie value for X seconds
      persist uie [HTTP::cookie "JSESSIONID"] 2700
   } else {
       Cookie wasn't set or didn't have a value, so check for the session ID in the URI
      set jsess [findstr [HTTP::uri] "JSESSIONID" 11 ";"]
      if { $jsess != "" } {
          Persist on the JSESSIONID URI value for X seconds
         persist uie $jsess 2700
      }
   }
}
when HTTP_RESPONSE {
    Check if the JSESSIONID cookie is present in the response and has a non-null value
   if { [HTTP::cookie "JSESSIONID"] ne "" }{
       Persist on the JSESSIONID cookie value for X seconds
      persist add uie [HTTP::cookie "JSESSIONID"] 2700
   }
}

Aaron

The 502 error indicates that you've got a reverse proxy layer in the mix too - like apache or similar. I'd look carefully at how they (it?) is behaving here as well. E.g., do you have anything configured there that could be contributing? Mind you, it may not be a smoking gun but it'll be a good data point to have...

 

 

-Matt

Matt is correct - 502 errors do indicate that there's a proxy in the mix (this wouldn't come from a standalone server, and the F5 isn't generating it). My suspicion is that something out there is running mod_proxy. Check out the bottom of this blog post:

 

 

http://www.techstacks.com/howto/set-up-jsessionidbased-persistence-on-a-bigip.html

 

 

Aaron. Thanks for the response and the update!