Hi all, On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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. > One more additional note. Databases use 2 phase commit to synchronize multiple databases. Similar method cannot be used because HTTP is stateless. i.e. Connections are closed. Even with HTTP/2, user may have multiple independent connections, i.e. multiple tabs, and there is no lock mechanism. It just cannot work. Therefore, 2 phase commit cannot be used. I cannot think of perfect locking mechanism that synchronize server and browser. i.e. Locking can be done by using additional cookie, but I cannot make sure browsers has synchronized time. If there is reliable locking, synchronous session management can be done. Even if there is, it would cost too much. e.g. Time consuming and too complex for the purpose. Ideas are appreciated. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
