Hi Jan!
My feedback on the four cases as following. It comes to my mind that this is a sensible topic and one should be aware/announce/discuss/test that as one might not know all the interactions regarding all projects/products running on glassfish/dev.net e.g.
! web service(stateful/stateless) products
! Authorization/Authentication products
! Clustering/Session transfer/Load balancing
[i]Case 1:
enableCookies: true
enableURLRewriting: true
-> jsessionid of new session stored in cookie *and* encoded in URL[/i]
-1: Pls see "
http://mail-archives.apache.org/mod_mbox/tomcat-users/200211.mbox/%3C3DDF619B.6020507@btopenworld.com%3E". Expected standard behaviour should be:(1)[i]>>>Tomcat does indeed know if a session id cookie was received (and you can
>>>find out as well, by calling request.isSessionIdFromCookie()). If that is
>>>the case, response.encodeURL() and response.encodeRedirectURL() will
>>>return the argument unmodified.[/i]
...else the jsessionid is encoded.
BUT (2)[i]">>>One subtlety should be pointed out, though -- consider what happens on the
>>>very first response for a new session. At that point in time, Tomcat has
>>>no idea whether the client supports cookies or not. Therefore, it sends
>>>the session id both ways (rewriting and a cookie). On subsequent
>>>requests, if the cookie has been returned, Tomcat will stop rewriting."[/i]
...hence if isSessionNew write cookie and encode url. On next request, behaviour(1) is in effect. So if cookie is transmitted on the next request, cookie supersedes url-rewriting.
Case 2:
enableCookies: true
enableURLRewriting: false
-> jsessionid of new session only stored in cookie (and not encoded in URL)
+1: But be aware/DOCUMENT that this can lead to loss/regeneration of session tracking if client does not accept cookies. Countermeasure in j2ee web layer project could be sending a redirect (plus adding a special http param for recognition purpose, else endless redirects) from a filter and then checking for cookie. BTW in the J2EE Tutorial these options are never mentioned/linked. One hint more that Case 1 should stay the default behaviour.
Case 3:
enableCookies: false
enableURLRewriting: true
-> jsessionid of new session only encoded in URL (and not stored in cookie)
+1: Especiall unit-test that a session cookie might still be sent in(e.g. cookie still valid out there on the browsers) but dev team opted to turn cookie sending off and redeployed. Okay, this might be more an in-development-case, but anyway.,, :-)
Case 4:
enableCookies: false
enableURLRewriting: false
-> invalid
-1: There might be projects out there which A) need no session tracking/stateless webapp OR B) opt for other session generation mechanism (?SSL session, custom,...). Developer is in charge to create web-session anyway, its not generated "automagically". Deployment MUST hence still be possible.
Jörg
[Message sent by forum member 'joma_javanet' (joma_javanet)]
http://forums.java.net/jive/thread.jspa?messageID=328536