Hi Chris,

Christopher Schultz wrote:
Christopher Schultz wrote:
| This means that, for users who are using both applications at once,
| all requests to '/foo' have TWO values sent for the JSESSIONID
| cookie. It appears that Tomcat will try both cookie ids and use the
| one that actually works (because this dual-cookie thing doesn't seem
| to confuse Tomcat). The problem is when a similar request goes to
| Cocoon (also running on Tomcat).

I checked the code for Tomcat (I'm using 5.5.23) and my assertion above
appears to be supported by the code. I'm using the Coyote AJP13
connector (which I believe is handled by
org.apache.catalina.connector.CoyoteAdapter) and the code in play
appears to be in parseSessionCookiesId:

This is not a real answer to your question, but if you look at the code, the behaviour w.r.t. multiple JSESSIONID cookies has been changed between 5.5.25 and 5.5.26. There is an issue BZ 43839, and the patch has been applied to TC 5.5 in r609463

http://svn.apache.org/viewvc?view=rev&revision=609463

Just wanted to prevent unnecessary confusion from differing code behaviour.

Regards,

Rainer


~        Cookies serverCookies = req.getCookies();
~        int count = serverCookies.getCookieCount();
~        if (count <= 0)
~            return;

~        for (int i = 0; i < count; i++) {
~            ServerCookie scookie = serverCookies.getCookie(i);
~            if (scookie.getName().equals(Globals.SESSION_COOKIE_NAME)) {
~                // Override anything requested in the URL
~                if (!request.isRequestedSessionIdFromCookie()) {
~                    // Accept only the first session id cookie
~                    convertMB(scookie.getValue());
~                    request.setRequestedSessionId
~                        (scookie.getValue().toString());
~                    request.setRequestedSessionCookie(true);
~                    request.setRequestedSessionURL(false);
~                    if (log.isDebugEnabled())
~                        log.debug(" Requested cookie session id is " +
~                            request.getRequestedSessionId());
~                } else {
~                    if (!request.isRequestedSessionIdValid()) {
~                        // Replace the session id until one is valid
~                        convertMB(scookie.getValue());
~                        request.setRequestedSessionId
~                            (scookie.getValue().toString());
~                    }
~                }
~            }
~        }

When there are multiple JSESSIONID cookies, the first cookie found
causes any URL-encoded session id to be discarded and the cookie's
JSESSIONID is used. Any subsequent JSESSIONID cookies will be ignored
unless a JSESSIONID has not yet been found that is valid. Once a valid
JSESSIONID is found, all other cookies are ignored.

Using LiveHTTPHeaders, I can see that the "correct" JSESSIONID (in my
case) is being sent /first/, followed by the incorrect one. That
arrangement of JSESSIONID cookies results in the first cookie being
accepted, then discarded as the second one is accepted in its place
(because the first one was apparently not valid).

It seems that I have two options:
1) Re-locate one of the applications -- which is not entirely trivial
~   since we have lots of links pointing to it
2) Change the cookie name used in one of the webapps (which violates
~   the servlet spec and is a PITA to implement)

Are there any other crazy options anyone can think of?

Thanks,
- -chris

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to