handles a request it creates a NEW session, thus a new file... Now that COULD be caused by the server not SETTING
the cookie in the 1st place, that I couldn't say!
It also seems ODD that the browser doesn't get a new session when it hits an old page. THAT makes me think the real problem is the URL the cookie is set for. If its set for just the individual page then this is exactly what would happen, you'd have an independent cookie (and session) for each URL (IE for each page).
Otherwise it sounds to me like his file session store is working the way you would expect. Every session has its own file and if you delete one then the Apache::Session logic happily creates a new empty one for you, and depending on the exact way the code is designed on the server side you may get a new sessionid and cookie to boot, I just don't have the code in front of me right now to look and see.
Sniffing the network traffic is definitely an easy way to see what is going on, ethereal will parse all the http headers nicely for you and everything, so its pretty easy using that. Mozilla also has a plugin for dumping request headers etc, though it seems to vary as to how well it works on any given machine...
Michael Nachbaur wrote:
[EMAIL PROTECTED] wrote:
Running <session:invalidate> causes the current session file to be deleted.
Hmmmm, the _file_? It should delete the session in the sessions file, but not the file itself.... That would cause the loss of all sessions...
Thats right. The users session file gets physically removed from the file system and subsequent page requests cause new files to be created on the filesystem (one for each new page request).
This is a symptom of the "File" datastore, rather than the default "DB_File" datastore that I believe Kjetil is using. The File datastore is easier to purge older sessions because you can take a look at the mtime of the file to delete it; it also helps with debugging a site, because you can see exactly which sessions exist.
However, it also introduces a rather nasty problem of thousands of files in a directory for popular sites. I believe this is where some of the confusion came in.
I am not specifically telling the browser to delete cookies in my script, I assume that session:invalidate does this as part of its invalidation process? (when I say 'deleting the browser cookies' I mean I have manually gone into the browser preferences and selected 'delete cookies' in an attempt to stop new files being generated on the filesystem). Although this had no effect and the session folder continued to fill up with new files.
I tend not to trust that feature of most browsers, as it doesn't work as I expect it to. I haven't sat down and performed any rigorous tests, but usually deleting a cookie will only cause the browser to stop reporting that cookie to the server when you restart the browser.
A good way to tell if this is what is actually happening is, if you are able, sniff your HTTP traffic and see if the browser is supplying the offending Cookie: header. But this might be more effort than you want to put out (I know it would be for me).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
