Hi, [----- this disucsses Bug 10419 and 10418. See details in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 and http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10418 with a bug-demonstration servlet http://www.freiheit.com/users/hzeller/SessionBugDemonstration.java this works with JServ and tomcat 3.2 but fails with tc 4.x --- ] > Your statement is incorrect. URL encoding does work, but it is a all-or-nothing > situation (ie, either you allow session cookies or you don't). Users do sometimes allow cookies for one situation and not for another. The applications shouldn't fail because of this - at least should the application server (tomcat) not make decisions that only the application developer can do. And letting an application fail because once the client used cookies but then in another session chooses not to is not good. Especially, since you cannot do anything to work around this problem in the application since this decision is made in tc. This makes things more fragile which is never good for enterprise quality. And I hope enterprise quality is what we should expect from the flagship of servlet engines! We always have the problem, that we might get multiple session ids (from the URL, from _multple_ cookies). The expected behaviour of getRequestedSessionId() is of course, that it should return a session ID that is (if possible) valid in our context, not just _any_ of the session IDs we got. The servlet spec is not very precise in this point stating, that the getRequestedSessionId() might not necessarily the same as the session in use. However, tomcats lookup mechanism for HttpSessions, does: the id returned by getRequestedSessionId() is the _same_ that is used to lookup the session in the context -- and if this is not a valid session id, we don't get _any_ HttpSession. Or a different problem caused by the same behaviour: Think of the simple use case that is explained in Bug #7588: if we have multiple sessions in different contexts that all use cookies, then all sessions will fail to work but the first one (having the first cookie) Problem here is: there are multiple cookies, but only one of it is valid in an specific context. Just fetching the _first_ cookie ist not possible: only the first application will work (because it can look up a valid HttpSession with the session id), but others not: the first cookie does not denote a valid session id in that context. So: if we use the result of getRequestedSessionId() to lookup the HttpSession (which makes sense), that we _have_ to make sure that we extract the sessionid from the multiple sessionids we might get in the request that actually makes sense in that context. Suggestion: The alternative would be to make getSession() [ HttpRequestBase.doGetSession() ] look itself in the http-request to look for a valid session id from the assortment of possible session ids. instead of using requestedSessionId. Even better would be to delay the determination of requestedSessionId until the context is known: on the first call of getRequestedSessionId() in the application [ and cache the result ]. This would enhance the performance as well in the HttpProcessor.parseHeaders(), since we do the check only if it is necessary at all (Delaying expensive operations is always a good idea). Ok, I'll prepare a patch for this, then we can discuss this. ciao, -hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
