Forum Discussion
dubdub
Sep 30, 2011Nimbostratus
Hi Aaron,
Here's a paragraph from the application owner, which undoubtedly explains it better than I can:
"This happens (users getting a 500 error on occasion) because the application server issues a session cookie that is stored on the user's computer and is associated with the open browser. As long as that session information is current, the application will work as expected. Should it expire due to inactivity (in the application server, not the browser or computer), the session information stored on the application server is invalidated, but it remains on the user's computer. When the application is interacted with, the application server is supposed to detect the invalid session information and transparently log the user back in via single signon. However, for certain scenarios this does not occur. The application server does not invalidate the session information stored on the user's computer and instead attempts to use it. Since it is no longer valid, it errors out and the end result is the HTTP 500 message."
This is a known bug in the application server and has been fixed in a recent service pack. Unfortunately, due to other constraints, we're not able to upgrade the application server at this time.
I like the idea of removing the cookies when a persistence record doesn't exist. Something along the lines of this?
when HTTP_REQUEST {
if { [session lookup uie "[IP::client_addr]"] eq "" } {
HTTP::cookie remove "first_cookie_name"
HTTP::cookie remove "second_cookie_name"
}
}
I am on 10.2.2 HF1, by the way.
Thanks,
Jen