Global.asa and the Lazarus cookie

[abraxas]

Hi,
Happy New Year to one and all!

I've come across an odd behaviour in Global.asa when trying to set a cookie. I've tried researching how global.asa stores some its info on the client but have only come up with....

"Session cookies are stored in the visitor's computers memory."

Which i gather means session variables which is interesting. I didn't know that.

When I have something like this in global.asa
Sub Session_OnStart
Response.Cookies("Cook1") = "Hello World"
End Sub

If I have a page somewhere that has this ..
Response.Write Request.Cookies("Cook1")

I get > Hello World
which is great!! But when I have browser that has Cookies DISABLED I still get "Hello World" ??? This is with all browsers. I tried closing the browser, deleting all cookies, played around with expiry dates but still > Hello World

I get the impression that all client orientated info between Start and End tags is stored in client memory and bypasses browser settings.

Does anyone have some thoughts about this?

The reason I'm doing this is that I am trying to establish a way of determing whether a client has cookies enabled without having to use javascript, that MTW browser thing and self-redirecting cookie evaluation.

Regards
abraxas

 

[Tarwn]

When you set a cookie in the same age load and then print it out again it won't matter whether it can make it to the end user, it still has a temporary value that is going to get sent to the end user. Since cookies are turned off the Session_OnStart is being called with every page load, here's why:
Session variables are not stored in cookie's, they are stored locally in RAM. However, the lookup key for a set of session variables that uniquely identify it with a specific end user is the automatically generated SessionId value. This value is used to key the session variables to a specific user and is sent to the end user in a cookie. What happens wen cookies are turned off? The webserver see's a request come in for a page without a session id cookie. So it generates a session id cookie, fires the Session_OnStart (under the assumption that this is a first visit) and treats the person like a new visitor. Unfortunatly when the user then goes to a second page the webserver again sees no SessionId cookie, so it treats them like a new visitor once again. If your writing session variables these will sit idle in your RAM until each session times out (default of 10 minutes).

So in your situation, a user comes to the site. Since they don't have a session d they are treated as a new user and the Session_OnStart is fired. This writes a value to the Response.Cookies collection that is going to be sent to the end user. Inside the page you load you attempt to read this cookie and are successful because it is still in the Response collection waiting to go out. Once the cookie is actually sent (with a cookie holding the SessionID) it will be throws away, butthe server doesn't know that. The user clicks over to a second or third page and the whole process starts again because they do not have the SessionID that wsas generated for them in the previous page, thus starting a whiole new session with every page/hit.

Hope this explanation helped,
-T

 

[abraxas]

Thanks Tarwn, that was very informative. I guess I'll think of a work around eventually.
abraxas