DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492 Strange Session id behavior Summary: Strange Session id behavior Product: Tomcat 5 Version: 5.0.18 Platform: Other OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm maintaining a JSP/servlet web using SSL, running on Apache 2.0.48 and Tomcat 5.0.18. Cookies are used for session identifier communication (not url rewriting). Some users using the web are experiencing very strange session id behaviour, the behaviour is like this: When these users make their first request to the web, they already have an session id that is invalid, i.e. request.getRequestedSessionId() is not null and the id is not a session id that has been recently created by Tomcat (I've a session listener in Tomcat that logs session creation and destruction). As expected, Tomcat creates a new session id for the users (because the session id is invalid) but the next requests from the users do not use that session id but instead continue to use the session id that they used in the first request. So Tomcat continues to create new session ids for each request, example: request.getRequestedSessionId() request.getSession(false).getId() request.getRequestURI() 01A960C22480CE9F445CDE48DE333F31 451BA13F85AE631148022C93DFDD2811 /first_request.jsp 01A960C22480CE9F445CDE48DE333F31 CBF44C3C065502D6397BC44A7AB659F9 /second_request.jsp 01A960C22480CE9F445CDE48DE333F31 6453C03AF5DD2B9EA1F27D225589E8B2 /third_request.jsp 01A960C22480CE9F445CDE48DE333F31 93F173966F28A972A2E70C32CC8E848B /fourth_request.jsp If the users close their browser and try again - they (most often) continue to have the same problem but request.getRequestedSessionId() is not the same as it was at last time... What could be the reason for this behaviour? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
