note 84242 added to function.session-regenerate-id

The problem of sessions being lost with small page reloads mentioned by "spam1 at dyden dot de" definitely exists (semi-solution below). It's easy to recreate by just creating a small script and hammering refresh. It may seem like you have to get up to ridiculous speeds to make it happen, but that's not so in the real world with a large framework, xmlhttprequests, dynamic images etc all going off. I've recreated it on a multitude of servers, OSs and versions of PHP and I'm glad to finally find someone else who has the same problem! The cause seems to simply be the user's browser not saving the updated cookie fast enough between pages. There isn't much that PHP itself can do to solve it (except maybe to keep X number of session files per user, rather than immediately deleting the old one). The simplest solution is to set delete_old_session to false, so when the second, third, etc requests go off with the old sessionid then the file is still available on the server. If you must use it with true then only do it during important operations like login, logout, etc. Problems will still exist but it'll be sporadic enough to prevent your user's from hammering support. ---- Server IP: 92.48.74.199 Probable Submitter: 81.151.1.230 ---- Manual Page -- http://www.php.net/manual/en/function.session-regenerate-id.php Edit -- https://master.php.net/note/edit/84242 Del: integrated -- https://master.php.net/note/delete/84242/integrated Del: useless -- https://master.php.net/note/delete/84242/useless Del: bad code -- https://master.php.net/note/delete/84242/bad+code Del: spam -- https://master.php.net/note/delete/84242/spam Del: non-english -- https://master.php.net/note/delete/84242/non-english Del: in docs -- https://master.php.net/note/delete/84242/in+docs Del: other reasons-- https://master.php.net/note/delete/84242 Reject -- https://master.php.net/note/reject/84242 Search -- https://master.php.net/manage/user-notes.php