-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rainer,
On 9/21/2009 5:23 AM, Rainer Jung wrote: > On 21.09.2009 00:45, Christopher Schultz wrote: >> >> Struts will get whatever session Tomcat hands to it, so this is really a >> Tomcat question: the current version of Tomcat will take all available >> JSESSIONID cookie values and give you the one that matches a >> currently-valid session. If none matches, I think you get an arbitrary >> session id returned from request.getRequestedSessionId and if you call >> getSession(true), you'll get a new session created. > > ... and in the current implementation they should be tried in the order > they are received from the client. Although I didn't find anything in > the SPEC which mandates or suggests that. Right, and there's nothing stopping your web browser from providing those cookies in arbitrary order. > If all fail, request.getRequestedSessionId() should return the value of > the last cookie, i.e. the least specific. "Should" in the sense that's > what I expect from current TC 6.0.x code, not in the sense of being the > best choice. Right: if Tomcat can't match /any/ of the JSESSIONID cookies to a valid session, the return value for request.getRequestedSessionId is arbitrary. Believe me, I got bitten by this when I had a Cocoon instance trying to forward session ids back to the "real" application with which it was sharing a URL space. We had a /third/ webapp sharing a URL space (yeah, it was dumb, but backward compatibility had to be maintained at least for a while) and they both were sending JSESSIONID cookies to Cocoon. Since Cocoon had /no sessions at all/, it could never determine which JSESSIONID cookie to send to the backend webapp. The problem was only somewhat deterministic... it appeared that if you visited our primary webapp first, then the secondary one, then Cocoon, then all was well (Cocoon would contact the primary webapp "correctly"). If the secondary webapp was accessed first, then the primary one, then Cocoon, Cocoon would fail because it would guess at the wrong JSESSIONID cookie. This was not reproduceable across all versions of all web browsers (I'm pretty sure that MSIE didn't act like the others... surprise, surprise) so we had no choice but to separate the URL spaces. The lesson I learned: never deploy a web application as ROOT if you have more than one web application to deploy. ;) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq4L0gACgkQ9CaO5/Lv0PCqowCfTf1V1J9wb+4vEUiR8MByjIDW iQ0AoJSWIywgt3XJojbo/E7QsbhPBB9i =eN9y -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
