How do you reconcile these two specs: HTTP Spec: Lifetime of Cookie * In its default state, a cookie erases when your browser closes. * If you want a cookie to last longer, you must set a time stamp for the expires attribute. Serv Spec: Session Timeouts * By definition, if the timeout period for a session is set to -1, the session will never expire.
PS: I was confused about the name, JSessionID and found out Spec says BOTH cookie name and URL suffix/parameter MUSTbe named JSessionID [ March 01, 2005: Message edited by: P. Dunn ]
A cookie lifetime lasts as long as a session lasts, which not always means when you close the browser. There are some settings that let you to work on the same session from different windows (I know, it's bad but that's it).
If you set the session-timeout to -1 it means that a session will never expire as long as the container will be up and running. However, if the series of circumstances for which a session is ended (note: not expired) occurs (in the normality of cases when a browser window closes), the session will also be invalidated. The expiration time is calculated by the following:
Now, the code is not EXACTLY like this, but it gives you an idea. If you want a Cookie to last more, you can use the Cookie.setMaxAge() method, which accepts an int (representing seconds) [ March 01, 2005: Message edited by: Marco Tedone ]
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
Joined: Feb 22, 2005
Yes, I see your point about normal curcumstances. Normally you'd shutdown the container at least a few times a year, I'd assume, making most of this issue theoretical.
However, this is the thing that is odd to me. If cookies must have an expiration date, a session timeout of -1 just means the session will last only as long as the cookie's expiration, which is determined arbitrarily by the container. So, effectivly, there's no "ever-lasting" session
BTW, in your code, correct me if I'm wrong, but I believe you meant [ March 02, 2005: Message edited by: P. Dunn ]
Joined: Jul 24, 2002
As regards cookies, their lifecycle doesn't control the session lifecycle, probably it's the opposite. As I said, even if the session timeout has got a value of -1, most of the time when the user closes the browser the session will be killed, and the cookie too.
As regards my code, I meant exactly what I wrote but obviously there are different checks to invalidate a session. I think it's possible to check how long a session has been alive by using the following code:
This is probably the mechanism used for the session-timeout element.
Your code would return a value which represents the interval between when you run your code and when the session was last accessed. If you meant to know the interval between the current request and the previous one, then your code is correct, provided that a setMaximumInactiveInterval() method was previously called. This way you could check if your result is > than getMaximumInactiveInterval() then HttpSession.invalidate, and this would be the second way of invalidating the session. [ March 02, 2005: Message edited by: Marco Tedone ]
Joined: Feb 22, 2005
If the cookie were gone, there would be no way to reassociate the user with the session. So it would never used again. An HttpSession that could never be reassociated with a user would be garbage, and for all practical purposes, invalidated. (Though it would still exist as an object.)
The cookie is not eliminated when the browser closes. It's reused until the cookie expiration date passes.
Though VERY ambiguous in the Servlet spec, I believe the session-timeout element is different from what you call "sessionLive." I believe the container periodically looks for expired HttpSessions. I would define InactivePeriod as measured from the LastAccessedTime to now, irrespective of creation time. The primary concern is reclaiming inactive session objects. I understand your interpretation, though.
Someone needs to rewrite the DTD where it defines: "The session-timeout element defines the ... session timeout..." Doh!