Hi Stas, On Thu, Mar 24, 2016 at 5:44 AM, Stanislav Malyshev <smalys...@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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
