-----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).
