This doesn't "set" a cookie to expire - why?

[Phil Powell]

// OBTAINED FROM http://www.javascripter.net/faq/settinga.htm

// NOTE THAT IF YOU SET days TO -1 THE COOKIE WILL BE SET TO YESTERDAY
AND THUS EXPIRE
function setCookie(name, value, days, docObj) {
var today = new Date();
var expire = new Date();
if (days == null || isNaN(days) || days == 0) days = 1;
if (days >= 1 || days < 0) expire.setTime(today.getTime() + 3600000 *
24 * days);
docObj.cookie = name + '=' + escape(value) + ';expires=' +
expire.toGMTString();
}


I am using this Javascript function to set a cookie to expire, and yet,
for some reason, when i set it to expire:

setCookie('my_cookie', '', -1, this.document);

It sets the cookie named "my_cookie" to the literal '' which does not
actually expire but still exist with the value of '', even upon page
reload!

I'm using Netscape 7.1 and IE 5.1 and happens on both

I want the cookie to be completely destroyed upon page reload, what
must I do?

Thanx
Phil

 

[Evertjan.]

Phil Powell wrote on 08 feb 2006 in comp.lang.javascript:

I want the cookie to be completely destroyed upon page reload, what
must I do?

Then do not set the cookie in the first place?

 

[Phil Powell]

That is not an option. Upon quitting the application the cookie must
be destroyed in order for redirection to take you back to the login
page. Server-side cookie destruction is handled but I believe not very
effectively.

Phil

 

[Evertjan.]

Phil Powell wrote on 08 feb 2006 in comp.lang.javascript:

Phil

[please do not toppost on usenet]

That is not an option.

Cann't you just change it's value to something inoffensive?

Upon quitting the application the cookie must
be destroyed in order for redirection to take you back to the login
page. Server-side cookie destruction is handled but I believe not very
effectively.

Oh wait, you are using serverside code?

Then it is much easier and safer to use session variables.
Even the whole session can be destroyed, deleting all session variables
as a perfect logout measure.

ASP: session.abandon
PHP: ???

 

[Phil Powell]

See below, thanx

Phil Powell wrote on 08 feb 2006 in comp.lang.javascript:

Phil

[please do not toppost on usenet]

That is not an option.

Cann't you just change it's value to something inoffensive?

Upon quitting the application the cookie must
be destroyed in order for redirection to take you back to the login
page. Server-side cookie destruction is handled but I believe not very
effectively.

Oh wait, you are using serverside code?

Then it is much easier and safer to use session variables.
Even the whole session can be destroyed, deleting all session variables
as a perfect logout measure.

Turns out the problem WAS server-side all along. Java that is. I was
using the parameter wrong for javax.servlet.http.Cookie method
setMaxAge.. in most C-derivative languages (TCL, PHP, etc.) to delete a
cookie you set it to yesterday's date ("today" - 86400), but in Java,
you set it to 0. I forgot about that.

So it works now the cookie is deleted and all is well!

Phil

 

[Thomas 'PointedEars' Lahn]

I want the cookie to be completely destroyed upon page reload, what
must I do?

That is not possible. Cookies will not be deleted before the session ends.
However, you could consider a cookie deleted if it has the empty string as
its value.


PointedEars

 

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

That is not possible. Cookies will not be deleted before the session
ends. However, you could consider a cookie deleted if it has the empty
string as its value.

Pointed, how do you define such "session"? Browser closure?

In my present vocabulary, only a server session has any meaning.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

Pointed, how do you define such "session"? Browser closure?

The moment of termination of the HTTP client process is usually considered
the end of the (client-side) session regarding cookies (ref.: session
cookie) which I was referring to.


PointedEars

 

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

The moment of termination of the HTTP client process is usually
considered the end of the (client-side) session regarding cookies
(ref.: session cookie) which I was referring to.

Can you translate that in the vulgate?

Does the "the HTTP client process" end by itself,
or what will cause it to end?

Can I as a user detect that ending?
[The little red light on the motherboard?]

Or is it as I asked: "Browser [window] closure?"

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

BTW: My nickname is PointedEars already, Eve.

Can you translate that in the vulgate?

You want a mouse-click-script-kiddie explanation instead of a
technically correct one? What kind of a developer are you anyway?

Does the "the HTTP client process" end by itself,
or what will cause it to end?

Usually user interaction will initially cause it to end, however other
processes can cause that, too.

Can I as a user detect that ending?

If you watch your process viewer/task manager closely, you probably can.

[The little red light on the motherboard?]

(ISTM you as a user will not even find that light.)

I was talking about software, not hardware.

Or is it as I asked: "Browser [window] closure?"

If it is a browser and there is a window, that is close to the truth.
However, a closed window does not mean necessarily that the respective
process was terminated. So it is incorrect to say that by closing the
window the cookie session ends, even if we restrict ourselves to the
GUI perspective on operating systems.


PointedEars

 

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

BTW: My nickname is PointedEars already, Eve.

Wow! I hope you are all ears.

You want a mouse-click-script-kiddie explanation instead of a
technically correct one? What kind of a developer are you anyway?

That is neither here nor there. If we all were of your standard we would
not be communicating at all.

Usually user interaction will initially cause it to end,

What is "initially cause it to end"?
It ends, but afther that it is not ended?

What user interaction will do that?
Please be specific.

however other processes can cause that, too.

So non-user interacted processes also
do "initially cause the session to end"?

What processes will do that?
Please be specific.

If you watch your process viewer/task manager closely,
you probably can.

I doubt a process viewer can see sessions.
So the session ending is really a process ending?

We would not need the term "client-sessions" after all.

[The little red light on the motherboard?]

(ISTM you as a user will not even find that light.)

[Secret: mine has a green light]

My name is not ISTM.

I was talking about software, not hardware.

Ah, so the pulling of the power plug will not end the process you call
"session"?

Or is it as I asked: "Browser [window] closure?"

If it is a browser and there is a window, that is close to the truth.
However, a closed window does not mean necessarily that the respective
process was terminated. So it is incorrect to say that by closing the
window the cookie session ends, even if we restrict ourselves to the
GUI perspective on operating systems.

Ah, a new concept: "cookie-session", what's that supposed to mean?

Again, I don't see any need for the concepts of "client-session" and
"cookie-session". You are only talking about a "process".

Let's keep "session" where it is usefull, on the server.

======================

I know that all cookies are destroyed by a sort of garbage collector on
closing [or perhaps reopening, closing can be dramatically sudden] of the
browser, but for those cookies having a expiration date in the local utc
relative future.

Cookies without an expiration date are called "ram-cookies" or wrongly
"session-cookies". I think "session-cookie" is a misnomer here, as a
session as I see it is an interaction between individual server and
browser. "Ram-cookies" is somewhat better, since those cookies need no
per-se HD storage.

The real session-cookie, is the cookie assigned by the server to identify
the server session. In that view, there can be more than one session per
server-browser complex.

 

[VK]

"client session" starts when you lauch the first instance of your
browser.
"client session" ends when you close the last instance of your
browser.

This is your current client session, a lot of data crap depends on this
timeframe. Say so-called "session cookies" (cookie set without
expiration date) are valid only till the end of your client session -
thus from the moment they are set and till you close the last instance
of your browser.

End of session doesn't mean immediate end of all processes. Say JVM may
stay running for another 1-5 minutes, ans some badly written ActiveX's
can hang up in the memory till the next restart. But these are
technical issues not related with the formal process.

Server-side session starts from the moment of authentification of a
particular machine and for the period defined by the server
administrator: usually from 1 hour up to 12 hrs. The persistence is
supported by cookie, by hidden form fields or by URL ?data and usually
connected with a session data file on the server. After server-side
session ends new authentification will be required. "Lost in action"
session data files (who left and never came back) are cleaned
periodically on the server by CRON jobs (or equivalents).

"client session" and "server session" are very different and equally
important terms.

I hope it helps.

 

[Evertjan.]

VK wrote on 09 feb 2006 in comp.lang.javascript:

"client session" starts when you lauch the first instance of your
browser.
"client session" ends when you close the last instance of your
browser.

Please quote on usenet.

Say so-called "session cookies" (cookie set without
expiration date) are valid only till the end of your client session

That's what I said, no need to repeat that.

The whole concept of client-session and "session cookies" is not needed.

 

[VK]

The whole concept of client-session and "session cookies" is not needed.

What is commonly called "session cookie" is a cookie without expiration
date. Its lifetime is defined by the end of the current client session.
End of client session doesn't necessary lead to the end of the current
server session. You can close all browser window, then launch one, go
to say Yahoo and you are still registered.

Maybe it could be possible to express all this much easier and in
lesser terms.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

BTW: My nickname is PointedEars already, Eve.

Wow! I hope you are all ears.

You want a mouse-click-script-kiddie explanation instead of a
technically correct one? What kind of a developer are you anyway?

That is neither here nor there. If we all were of your standard we would
not be communicating at all. [...]

Figures that someone like you who is incapable of following Internet
standards is also incapable of a constructive discussion. Go troll
elsewhere.


PointedEars

 

[Phil Powell]

Side note:

I fixed it! Turns out the problem was never Javascript but my
server-side Java all along, whereby javax.servlet.http.Cookie method
setMaxAge must take the parameter "0" to ensure that the cookie will be
deleted after page reload (or new page load).

Thanx for your help!

Phil

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

Evertjan. wrote:
Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in
comp.lang.javascript:
Evertjan. wrote:
Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in
comp.lang.javascript:
Phil Powell wrote:
I want the cookie to be completely destroyed upon page reload,
what must I do?
That is not possible. Cookies will not be deleted before the
session ends. However, you could consider a cookie deleted if it
has the empty string as its value.
Pointed,

BTW: My nickname is PointedEars already, Eve.

Wow! I hope you are all ears.

how do you define such "session"? Browser closure?
The moment of termination of the HTTP client process is usually
considered the end of the (client-side) session regarding cookies
(ref.: session cookie) which I was referring to.

Can you translate that in the vulgate?

You want a mouse-click-script-kiddie explanation instead of a
technically correct one? What kind of a developer are you anyway?

That is neither here nor there. If we all were of your standard we would
not be communicating at all. [...]

Figures that someone like you who is incapable of following Internet
standards is also incapable of a constructive discussion. Go troll
elsewhere.


PointedEars

 

[VK]

Side note:

I fixed it! Turns out the problem was never Javascript but my
server-side Java all along, whereby javax.servlet.http.Cookie method
setMaxAge must take the parameter "0" to ensure that the cookie will be
deleted after page reload (or new page load).

Thanx for your help!

LOL!

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 2/9/2006 6:20 PM:

Thomas 'PointedEars' Lahn wrote on 09 feb 2006 in comp.lang.javascript:

Can you translate that in the vulgate?
You want a mouse-click-script-kiddie explanation instead of a
technically correct one? What kind of a developer are you anyway?

That is neither here nor there. If we all were of your standard we would
not be communicating at all. [...]

Figures that someone like you who is incapable of following Internet
standards is also incapable of a constructive discussion.

That is hilariously funny coming from someone who is incapable of
following Internet standards himself.

 

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 10 feb 2006 in comp.lang.javascript:

Can you translate that in the vulgate?

You want a mouse-click-script-kiddie explanation instead of a
technically correct one? What kind of a developer are you anyway?

That is neither here nor there. If we all were of your standard we would
not be communicating at all. [...]

Figures that someone like you who is incapable of following Internet
standards is also incapable of a constructive discussion. Go troll
elsewhere.

It seems that you cannot explain your answer in reasonable terms and revert
to abusing the questioneer instead.

There are only two possibilities:
1 you are realy incapable to explain your ideas, because your standard is
not as high as I said above.
2 you are unwilling to explain, because you are only interested in your own
aura.

I strongly hope it is the first, because I wouln't like you to belong to
the second group. Either way it is you that blocks your "constructive
communication".

 

[Phil Powell]

You all need to sit down together, in real life, no computers, and face
each other and see what happens.

Again, thanx for all your help, like I said it was the server-side
cookie setting that was the problem all along!

Phil