Hi all, On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski <s...@digitalsun.pl> > wrote: > >> Doh, it's happening again, it was discussed before. Anyway, your solution >> seems to not fix the real problem behind the bug entry. I suspect that >> following scenario may occur: >> > > Of course it was. I remember well. > Discussion was not going well because people does not understand > nature of web session. i.e. Session management is asynchronous. > > It works almost always under stable network, but it cannot with unstable > network. > > >> >> http://lxr.php.net/xref/PHP_5_4/ext/session/mod_files.c#429 >> >> scenario could be as follows: >> >> 1. request A is done with sessid=123 >> 2. A calls session_regenerate_id and is preempted after unlink(2) but >> before >> access(2) >> 3. request B is done with sessid=123 - session_start creates the session >> 4. request A wakes up, session is written to fs by request B, so destroy >> fails >> >> Please note that if destroy fails, then new session is not generated, >> possible (but ugly) solution is to call session_regenerate_id again. >> > > It just does not work. > How do you keep session for lost session? > > Lost session occurs like > > 1. Server executes session_regenerate_id(true), delete old data and send > new session ID with copied data to browser. > 2. Unstable network lost packet that sets new session ID. > 3. Browser thinks old session ID is valid, but there is no session data > for it. > > Besides, there is issue that session data must be deleted may keep alive > forever. Current session management is not predictable and precise at all. > > If there is better idea other than the RFC, I appreciate it. > BTW, if there are users who do not care about mobile devices at all, they can simply set session.destroy_ttl=0. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
