Bug #61470 [Asn->Csd]: session_regenerate_id() do not create session file

Edit report at https://bugs.php.net/bug.php?id=61470&edit=1 ID: 61470 Updated by: yohgaki@php.net Reported by: david at grudl dot com Summary: session_regenerate_id() do not create session file -Status: Assigned +Status: Closed Type: Bug Package: Session related Operating System: ANY PHP Version: 5.4.0 Assigned To: yohgaki Block user comment: N Private report: N New Comment: It's fixed already. Probably by use_strict_mode patch. Test for this bug is added. http://git.php.net/?p=php-src.git;a=commitdiff;h=fb803ff81993eb8acde0cdd5f513b6253221c349 Previous Comments: ------------------------------------------------------------------------ [2014-10-29 10:57:02] webmaster at tubo-world dot de Let's be concrete. session_start(); session_regenerate_id(); // send headers // new request between new session id and written session id session_write_close(); The only place where session data could be lost is when a new request comes with a regenerated session id that is not saved yet. Now you propose to create the session file/lock already in session_regenerate_id to circumvent the problem. This way the new request will definitely block. This would solve the problem for the 'files' save handler indead. BUT there is no way this behavior can be replicated for custom save handlers! session_regenerate_id does not call any methods of a save handler. So custom save handlers would never be able to also create a lock. This is way I said, the only solution in the moment is for users to make sure the regenerated session is saved before the headers are sent. Then there is no problem at all. So to me this is more a documentation issue and I don't think PHP can do anything here with the current design of the session extension. ------------------------------------------------------------------------ [2014-10-29 06:46:36] yohgaki@php.net Oops. Hit submit button too early, but I think you can get what I mean. ------------------------------------------------------------------------ [2014-10-29 06:44:27] yohgaki@php.net Right. Even when session ID is not shared explicitly, locking could be useful. As we knew, most browsers supports multiple connections (6 or so). Once session ID is set by cookie, then subsequent request would request the new session ID that the date is not stored yet. (i.e. no data file/record) This behavior could damage session data consistency. This could be rare, but the app might be affected by this is perfectly valid app. ------------------------------------------------------------------------ [2014-10-29 03:53:58] david at grudl dot com > there cannot be two concurrent requests for the same session? They can be. session_regenerate_id() sends new cookie and next request is concurrent with the current request. ------------------------------------------------------------------------ [2014-10-29 01:41:46] webmaster at tubo-world dot de @yohgaki: I don't get it. Session file is created for locking on session_start for the given id. But with session_regenerate_id you create a new, random session id. How would locking/creating a session file make any difference when there cannot be two concurrent requests for the same session? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61470 -- Edit this bug report at https://bugs.php.net/bug.php?id=61470&edit=1