-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
On 9/14/2010 7:55 AM, Mark Thomas wrote: > On 14/09/2010 10:40, Brian McBride wrote: >> The javadoc states this call returns the "session associated with the >> request". I'm trying to figure out what "the session associated with >> the request" actually means. >> >> Specifically, if I have the same client sending https and http requests >> intermixed in time, will there be two sessions objects, one for the >> secure requests and one for the insecure ones, or just one. > > It depends where the session is created. Sessions created under http > should transition to https (and back) without a problem. If you create > the session under https then the session will not transition to http. > The next http request will trigger a new session to be created. Just for my own edification, consider the above scenario, and then follow these steps: 0. [Browser has two JSESSIONID cookies: one secure=true and one secure=false] 1. Browser makes an HTTPS connection to the server and sends both cookies 2. Application code calls request.getSession() Which cookie does Tomcat end up using? My experience with Tomcat and foolish JSESSIONID cookie handling (a big mistake in the past with nested URL spaces and proxied session ids) taught me that Tomcat will take the JSESSIONID cookies from the request and try them all: the first one that is valid wins. Does this mean that the session chosen during step #2 above is entirely dependent upon the order in which the client sends the JSESSIONID cookies? Or, does Tomcat prefer the HTTPS one when in HTTPS mode? I'd read the code, but I have forgotten where that code was when I read it long ago. (*ducks*) Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPg6QACgkQ9CaO5/Lv0PCzTgCeNzvKvdaLw6wGDcE+NXYMd5XM b/sAnitcE4twHuaC41qfgV0R6xazv3rB =ponm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org