On 26 January 2016 at 12:17, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> I'll appreciate if one could find defect if there is. The problem is that you're trying to build on a foundation of sand. The session handling works but is incredibly fragile. Or to put it more colloquially this is a "how to get to Dublin problem". To get to having a more secure and reliable session handling, we need to start from some where else, not just keep building on top of the current session handler code. The proposed RFC is not a good way to proceed. Having functionality depend on setting values in an array like this (as far a I've undertood the RFC): // Resend new session ID once. This will reduce chance of client // race and lost session by unstable network to acceptable level. $_SESSION['__PHP_SESSION__']['NEW_SID_SENT'] = time(); is not a sensible way of programming imo. Additionally, changing code that is apparently very fragile and so breaking people's applications in subtle ways, is not something we should be doing. > Anyway, we may be better to talk about how it should be. > For this thread, how session management should be. > It's just not good enough currently. To me, there are two good ways to proceed: i) Develop a new session extension, that doesn't depend on magic behaviour of globals and leave the current session handler as it is. The new session extension could be shipped as a 'work in progres' when it's good enough, before PHP 8. Then when it's stable, we could figure out how to transition users from the old extension. ii) Develop a session handler in userland code only. PHP is powerful enough to support this. Although obviously there are big benefits to shipping a session handler with PHP, I don't see any need for it to be done internally other than we don't currently have a way of shipping userland code with an extension. I'm hoping that before PHP 8, the ability to ship PHP code as part of extensions would be in place. Either of those two would be feasible. The proposed RFC doesn't appear feasible to me. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
