note 62445 added to function.session-destroy

In response to the difficulties that some are having with fully destroying a session (especially with session files remaining on the server) I find that this usually happens when the user is not sent to a "dead" page after the session is destroyed. Just like any other cookie, changes to a session cookie won't take place immediately on the page at which the command is issued. Try: session_start(); session_destroy(); print "You have been logged out."; At this point, the user's session file should have been cleared off of the server. The only way the session id might then be reused (causing the session file to reappear) is if the user's browser remains open and they initiate a request that calls session_start again. Since the browser will still have the session id cached, PHP may use the same id again and basically re-create the session file. This behavior is fine as long as you understand it. This is the behavior I have observed and tested using PHP 4.4.2 and RHEL 4. This might sound too simple to be your problem, but give it a try. If you're having to go through step after step to kill off stubborn sessions, this is probably why. ---- Server IP: 216.194.113.175 Probable Submitter: 72.64.104.25 ---- X-Spam-Status: No, hits=3.1 required=5.0 tests=DATE_MISSING,FROM_NO_LOWER autolearn=no version=2.64 ---- Manual Page -- http://www.php.net/manual/en/function.session-destroy.php Edit -- http://master.php.net/note/edit/62445 Del: integrated -- http://master.php.net/note/delete/62445/integrated Del: useless -- http://master.php.net/note/delete/62445/useless Del: bad code -- http://master.php.net/note/delete/62445/bad+code Del: spam -- http://master.php.net/note/delete/62445/spam Del: non-english -- http://master.php.net/note/delete/62445/non-english Del: in docs -- http://master.php.net/note/delete/62445/in+docs Del: other reasons-- http://master.php.net/note/delete/62445 Reject -- http://master.php.net/note/reject/62445 Search -- http://master.php.net/manage/user-notes.php