Setup: ~~~~~~ I have two contexts. The root context allows cookies and the sub context does URL rewriting. ie: <Context path="" docBase="sub" reloadable="true" privileged="false"/> <Context path="/sub" docBase="sub" cookies="false" reloadable="true" privileged="false"/> In the docBase is only an index.jsp which justs print out the session and cookie info and does encodeURL() for the link to the sub context. If I do: 1) goto http://localhost:8080/index.jsp (uses cookies) 2) goto http://localhost:8080/sub/index.jsp (uses URL rewrite) 3) click on the link which is response.encodeURL("/sub/index.jsp") Issue: ~~~~~~ I find that the root context's cookie is passed onto the sub context. Because of this the encodeURL() doesn't encode the URL for rewriting in the sub context. Each time I click on the response.encodeURL("/sub/index.jsp") link a new session id is generated each time. Example: ~~~~~~~~ Request URI = /sub/index.jsp Session ID = 80A6E1BEC167333A8E05E3588EA0C3A8 Is New = true Is Valid = false From Cookie = true From URL = false Cookie[0] (from /index.jsp) getComment() = null getDomain() = null getMaxAge() = -1 getName() = JSESSIONID getPath() = null getSecure() = false getValue() = F436A1045778EC9E794449A0192BD406 getVersion() = 0 ------------------------- Because request.isRequestedSessionIdFromCookie() returns true (since the root's cookie is passed to the sub context) the URL is not encoded with the sub context's session id. I've tried this on Windows & Linux, and with IE & Firefox...all produced the same results. I've attached example of this issue.
Created attachment 12736 [details] example tomcat instance of this issue.
This seems contrived... What's the use-case for it? I'm just curious, not closing this issue at this point.
Our use case is that our system is half web-based and half applet based. The applets communicate with our servlets, setup sessions, redirect users to various web pages. All this has to be done through URL rewriting because the cookie caches aren't shared between broswer and the applet. This is in the /sub context. Now we have a members section that is cookie based on the root context. We tried linking some features of the members section into the applet so it's accessible in the applet. But whenever the user goes to the member section all access to the /sub is "screwed up" like how I mentioned before: the URL rewriting in the sub context doesn't take because of the cookie at the root context. Lets see workaround for us... 1) rewrite our site to use URL rewriting instead of cookies. 2) move members ares to a separate /sub2 context. Can't do that because they still access pages from / -------------------- But use case aside, it just seems like a bug: I specify that the /sub context is not to use cookies (force URL rewriting) and it's not using the session ID given on the URL because the root context uses cookies. I would it expect it use URL rewriting instead of not being able to use anything. I don't know if there is a spec covering URL-rewriting so I can't refer to anything other than it being vendor specific.
forgot to mention that for the workaround of forcing users to use URL rewriting for the members section that this goes back to the usual debate of URL rewriting vs. cookies where if the user navigates away from the site and comes back then the URL rewritten session is gone.
I knew we never should have added the option to disable cookies ;) The Servlet Spec doesn't require containers to provide this option, and it seems to be it just leads to bad stuff ;) But now that we provide it, we have to maintain it I suppose. <sigh />
If you want this fixed, submit a patch for it. I'll be glad to evaluate and commit it as needed. As evidenced by the length of time (nearly 2 months) since you submitted this issue, no committers care about it enough to spend time investigating/resolving it.
Hmm, two weeks since patch request, two months since initial issue. Please reopen this if/when you have a patch ready. I'll be glad to evaluate and commit it then. Thanks.
(In reply to comment #6) > If you want this fixed, submit a patch for it. I'll be glad to evaluate and > commit it as needed. As evidenced by the length of time (nearly 2 months) > since you submitted this issue, no committers care about it enough to spend > time investigating/resolving it. I don't see how commiters are the one that decide in which direction the code evolves, where it is being fixed or not It should be driven by someone, or a group of people, acting as 'drivers', based on how critical are bugs and users requests This is the only way for the apache group to keep users confidence !
Created attachment 14294 [details] Patch for issue Hey Yoav, I've got a patch for this. Finally got some time to track it down. Currently the cookie session ID always overrides the URL session ID, regardless if the context enables cookies or not. This patch will check to see if the context enables cookies first. If it does then the cookie session ID overrides the session ID from the URL. If it does not then the parseSessionCookieId is skipped completely.
I do not agree with this patch in the general case. If a cookie is submitted, we'll use it.
(In reply to comment #10) > I do not agree with this patch in the general case. If a cookie is submitted, > we'll use it. I agree with that with one exception. This is not a general case, it's a use case where the (sub) context disables cookies and is expecting to use URL rewriting. The presence of the (ROOT) cookie forces a new session on each request since the URL rewriting is always overriden by the cookie, thus making the (sub) context unusable. Mixing cookies and URL rewriting is okay when the ROOT context doesn't use cookies (ie: /subA uses cookies, and /subB uses URL rewrite). Thought it would be easier to make the patch since this use case seems like a bug. See my comment #3 for additional reference. More workarounds that I thought of are: * create a host listening on a separate port. However this port may get blocked by firewalls since it's not port 80. * setting up a separate domain and use URL rewriting just in that domain. * don't use cookies at all. Not my favorite. I just don't want other people to experience the trouble that I had. If the decision is still a WONTFIX, then please add a note in the docs for the cookies attribute for Context that URL rewriting won't work for sub contexts if the ROOT context uses cookies. thanks.