-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 12/6/12 2:40 PM, André Warnier wrote: > Christopher Schultz wrote: >> Yes, but session cookies typically have an expiration of "-1" >> which means "when the browser exits". Never exiting the browser >> has predicable consequences, here. > > So for this case, the solution would consist in setting a timeout > for the cookie. Since the container (generally) manages the cookie timeout, most applications don't ever directly touch the JSESSIONID cookie or its timeout. > If the cookie times out, the browser will not send it anymore when > the user comes back, mod_jk will route this to any tomcat, which > will start a new session and set a new cookie. CQFD. That is true, but it would be a shame for the cookie to time out before the (server-side) session was actually destroyed. I think this is a legitimate gripe. >>> - if it is appended at the end of the URL, then how could the >>> server get rid of it (in the browser's displayed page) ? >> >> Set a new value for the JSESSIONID cookie. > > Well no, not in this case. (Sorry, I just noticed that you said "at the end of the URL". I was still thinking about cookies. If the jsessionid is in the browser, you'll have to redirect the client with a different (or missing) jsessionid parameter. > The OP says : because the previous user does not close his > browser, walks away for a while to have a drink, and comes back. In > the meantime, the session has expired but the old page containing > the URL links with the expired "jsessionid.jvmroute" tagged at the > end is still there, sitting in the browser's window.. So now the > user clicks on a link of that old page, which sends a request to > the server, with the expired session-id. But because of the > tagged-on old jvmroute, mod_jk sends it through to the same tomcat > as before. Which is what he is trying to prevent. Until now, Tomcat > hasn't sent anything, so it had no opportunity to set a new > jsessionid. Right. Honestly, the same is true for the cookie situation: Tomcat had no initial opportunity. > My question was thus : how can one even imagine to have tomcat or > mod_jk or Apache httpd go clear these links (with the expired > jsessionid.jvmroute) out of the browser's currently displayed page, > when the session times out. Obviously they can't. Right, they can't. My suggestion is an invalid-session event to trigger a re-balance at the mod_jk (or mod_proxy_ajp) level. If Tomcat can use some obscure response code (306? 308/9?), perhaps that could trigger a re-balance in httpd. When such a re-balance happens, the new backend server would ignore both the cookie and the jsessionid (because the jvmroute does not match the current server) and produce a response with a new Set-Cookie and re-written URLs (if appropriate). > Just tell me : if I happened to know the session-id and the > jvmroute, would there be any request which I could send to Tomcat, > which would not have any non-idempotent effect, and which would > tell me if that session is still valid ? AFAIK, Tomcat does not have a "ping" operation for a session. If you make a request that touches the session, you'll freshen the last-used timestamp and extend the life of the session. You must have read enough "I have a javascript ping to check my session status on the server, and no my sessions never expire!" posts on the list to be aware of this. > (On second thought, of course there would : one could just build > one into the application). That might get tricky. I'm not sure if you can even ask Tomcat if the session is valid without it updating the last-touched time and extending the life of the session (which I believe is *not* what you want, here). > I'm heading for the patent office. Andre::CrystalBall sounds nice > too. Right. Pid's probably should be: import com.pid.omniscience.CrystalBall; anyway. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDBIj8ACgkQ9CaO5/Lv0PC+0QCdFTe7kRkUmrWiakKZVPFA7mPk 5tIAoJlZbQl5/2T6ZqxOSC8p1C15DiB9 =CQAy -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
