Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91881
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.67 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <56F30047.3090707@gmail.com>
References: <CAGa2bXZqCd4g5BwzRxWsVw351G_o1+AkhGq3cdyKhUW39rm4Tg@mail.gmail.com>
 <56F1A28F.90000@pascal-martin.fr> <CAPhkiZyn1hh_kdR5sMCxHSw+=kabiPerNT8Y3o8-h6u9d45wNA@mail.gmail.com>
 <CAGa2bXaWFqM3n4swF8bpVNXo6vzCipSpJXgjBq2_xd1ou6TgMw@mail.gmail.com> <56F30047.3090707@gmail.com>
Date: Thu, 24 Mar 2016 08:06:12 +0900
Message-ID: <CAGa2bXaNrGeViKg04jW8J-MUCEsF_iVgvEHC1q-8Se3sYN9uQA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andrey Andreev <narf@devilix.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE] Precise session management
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Stas,

On Thu, Mar 24, 2016 at 5:44 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> Offending features may be disabled/changed by INI settings. I think it ok
>> to say pretty much no BC issue.
>
> I think this approach will lead us into problems. "It may be disabled by
> INI setting" does not mean the problem does not exist (and btw not
> everything that changes can be disabled AFAIR). Most BC breaks have
> workarounds, but they still are BC breaks. Moreover, some of the changes
> are default changes, which means basically users will have to undo what
> this RFC does - if we think they'd have to do it, why change it in the
> first place?

Right. Not everything cannot be disabled, but it should be matter for
applications. Session data is managed more strict manner by
timestamping and apps do not have to care about it. It just works more
precisely than now.

Only concern is test program that inspects session behaviors. New
session will not delete session data immediately and contains
additional array. Therefore, save handler function execution order
changes and test program may detect existence of to be deleted
sessions and/or additional array.

>
> I also feel that sheer size of this RFC, the fact that it tried to fix
> many unrelated issues, and amount of changes it brings leads to the
> situation where people don't really discuss it properly but instead rely
> on claims in the RFC that everything is fine, because it is very hard to
> properly consider changes of this size with this many moving parts. At
> least the discussion on the list was rather scarce as far as I can see.

I'll try to divide into pieces next time.

>
>> The difference that user/3rd party save handlers will see is an additional
>> array in session data. The additional array should not cause any problems
>> with session save handlers.
>
> The change is not limited to additional data. This additional data is
> active - it controls how sessions are supposed to behave. All these need
> to be updated when something happens, all these need to be checked,
> validated and user for various logic on various stages of session
> lifetime. So saying "it's just some additional data, nothing of it" is
> not true - it's not just data. Maybe everything is still OK with the
> session handlers - but this needs to be thoroughly verified, it does not
> come for free.

As you mentioned, this RFC contains BC. Most important for apps is
automatic session ID regeneration. Automatic session ID regeneration
is enabled by default, but it can be disabled if apps cannot support
this. Another issue is obsolete session data. Currently, it is left
for GC or removed immediately. Leaving obsolete session data to GC is
not good, but removing it immediately is not good also. We need to
change the behavior.

The basic logic is used and tested by very large site, so it can be
said it's tested and worked.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net