Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85341
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.178 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <20150320101241.GA69273@mail.digitalsun.pl>
References: <CAGa2bXb2qm3Y0S_dVDe+Orh6kbuuQOOgLNc_VwycZCCiSxPZ2w@mail.gmail.com>
 <CAGa2bXauT9Kq74FDqq+0gyGUUa5FRirkryRHtBVei5hLJHbVUw@mail.gmail.com> <20150320101241.GA69273@mail.digitalsun.pl>
Date: Sat, 21 Mar 2015 06:43:34 +0900
Message-ID: <CAGa2bXZjXGQvb+h+ygB2A-KK1Zg=jvoiu0Oq1C6nOH37=bL+SQ@mail.gmail.com>
To: Mateusz Kocielski <shm@digitalsun.pl>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c036a4b31f460511bf37f0
Subject: Re: [PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly
 generates a warning and loses session data
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c036a4b31f460511bf37f0
Content-Type: text/plain; charset=UTF-8

Hi Mateusz,

On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski <shm@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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c036a4b31f460511bf37f0--