Hi Joerg,
On 01/27/09 17:15, glassfish_at_javadesktop.org wrote:
> 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.
Right, but IT 3972 complained about the fact that there was no way to
disable the
encoding of the jsessionid in this case. This is where the
"enableURLRewriting" property
in sun-web.xml (a GlassFish enhancement over Tomcat) will become
relevant, see below.
> On next request, behaviour(1) is in effect. So if cookie is transmitted on the next request, cookie supersedes url-rewriting.
>
I completely agree with you. When I listed the various cases, I was only
concerned about the
isSessionNew case (that's what I meant by "jsessionid of new session").
That is what IT 3972
was all about. I'm not talking about subsequent requests: For those, the
presence of a cookie
will supersede any "enableURLRewriting" setting. Sorry if I was not clear.
What was needed was a way to disable URL rewriting for a newly created
session. With the fix for
IT 3972, URL rewriting was disabled by the mere presence of
"enableCookies=true". But as Paul
pointed out, this behaviour was too coarse-grained. This is now fixed by
adding support for the
"enableURLRewriting" property. In fact, I've changed the URL rewriting
code in Response.java
(isEncodeable) as follows:
Index: Response.java
===================================================================
--- Response.java (revision 24476)
+++ Response.java (working copy)
@@ -1503,8 +1503,8 @@
return (false);
}
if (hreq.isRequestedSessionIdFromCookie() ||
- (getContext() != null && getContext().getCookies())) {
- return (false);
+ (getContext() != null &&
!getContext().isEnableURLRewriting())) {
+ return false;
}
As you can see, URL rewriting will now be disabled if the request
carried a JSESSIONID
cookie (to resume a session) or URL rewriting has been disabled (by
setting "enableURLRewriting"
in sun-web.xml to false).
org.apache.catalina.Context#isEnableURLRewriting() is a new method I
added, which returns the
value of the "enableURLRewriting" property in sun-web.xml.
>
> 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.
>
Yes.
> 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.,, :-)
>
Agreed. In fact, our request processing code already does this: Don't go
looking for JSESSIONID cookies if
"enableCookies" has been set to false.
> 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.
>
OK, good point. Notice that GlassFish does not (yet) support session
tracking via SSL id, see
this RFE:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4589
("Add support for session tracking via SSL session id"), but I agree
that disabling both cookies
and URL rewriting should be possible in order to support any custom
tracking scheme.
Thanks so much for your feedback and comments, Joerg!
They have been very useful. :)
Jan
> Jörg
> [Message sent by forum member 'joma_javanet' (joma_javanet)]
>
> http://forums.java.net/jive/thread.jspa?messageID=328536
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>