File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Cookies and session timeout Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Cookies and session timeout" Watch "Cookies and session timeout" New topic

Cookies and session timeout

P. Dunn
Ranch Hand

Joined: Feb 22, 2005
Posts: 34
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.

It seems "never expire" means a really long time, because cookies require a time stamp. I wonder how it's done. Do the containers decide what "forever" means (eg, 30 years)?

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 ]

Ranch Hand

Joined: Jul 24, 2002
Posts: 379
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
P. Dunn
Ranch Hand

Joined: Feb 22, 2005
Posts: 34
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 ]
Ranch Hand

Joined: Jul 24, 2002
Posts: 379
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:

sessionLive = System.currentTimeMillis() - HttpSession.getCreationTime()

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 ]
P. Dunn
Ranch Hand

Joined: Feb 22, 2005
Posts: 34
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!

PS To Add one other odd detail:
According to the DTD:
* If the timeout is 0 or less, session will not expire.
According to the API:
* setMaxInactiveInterval(int interval)if interval<0, session will not expire.(if interval==0, session expires immediately. Wow! Somebody fix that!)
For cookies:
* A negative value means that the cookie is not stored persistently and will be deleted when the Web browser exits. A zero value causes the cookie to be deleted. (Though different it makes sense, because cookies must have some timestamp.)
Colin Fletcher
Ranch Hand

Joined: Sep 10, 2004
Posts: 200
To add one more point of clarification...

the cookie name is JSESSIONID and the url parameter name is jsessionid

They are case sensitive.

My interpretatiom of Session Timeout is inactive time (Now - LastAccessTime)


SCJP 1.4 SCWCD 1.4
P. Dunn
Ranch Hand

Joined: Feb 22, 2005
Posts: 34
Thanks! good catch.
I agree. Here's the link:
subject: Cookies and session timeout
It's not a secret anymore!