DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38357>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38357 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsled- | |[EMAIL PROTECTED] ------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 16:03 ------- (In reply to comment #4) > This cannot work as your backend server does not set a session route. The > session route must be added to the session value and has to be separated by a > '.'. So the contents of your jsessionid should be something like > > 5C16625C0C45A7EF33487CCC19016A34.first This is really not obvious, and not described in the doc. :/ In our (I imagine common) setup, we assume the session ID will be sufficiently unique such that we don't need to further discriminate between specific app servers. After thinking about it, I see the value of using '.' ... you can have collisions in the session ids themselves, and use the post-'.' section to strictly control stickyness of the dispatching. But I'll echo support for the comments about not necessarily being able to control this string in servers, let alone principle of least surprise about the behavior without the '.'-parsing. If the whole token was always used, both the common random-sessionid-is-unique-enough case as well as the qualified-by-a-particular-server-name case would both work. (experienced here with apache-2.2.4 and resin-3.x) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
