Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory

Hi Stas, On Mon, Jan 20, 2014 at 11:56 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > > Vote period: 2014/01/20 - 2014/01/30 > > https://wiki.php.net/rfc/session-lock-ini > > > > New comments and questions are welcomed. > > I see there are three proposals there, but only one vote. E.g. I think > unlocked sessions are not a good idea, but lazy write may be ok (btw, > interaction between no-lock and lazy write can lead to completely > undebuggable scenarios when same data by same code sometimes are written > and sometimes are not depending on session state). It is made a single RFC so that everyone understand new features. I agree that unlocked session could be a cause of hard to debug bugs and it should never be a default. Even if unlocked session can be dangerous, there are save handlers that support unlocked session for better performance. e.g. memcache. It would be reasonable to support by module. Unlocked session could be more usable by session.lazy_write. According to current implementation, "the last session wins". With session.lazy_write, "the last session *writes data* wins". This behavior prevents loosing updated data. It's better for performance also. > I'm not sure I even > understand what lazy_destroy does - if the data is deleted then it's > deleted, how can it be accessible and why? > With AJAX or browser supports concurrent access to server, concurrent access to server is possible. When session ID is regenerated, it is possible that some connections access to server with old session ID. i.e. Race condition. When this happened, old session that may be known to attacker may be reinitialized or new unneeded session ID is created when use_strict_mode=On. Allowing access to old session data for a while prevents these cases that initialize unneeded session. RFC proposes deletion flag in $_SESSION. It's a little dirty, but it's faster and simpler. It would be acceptable because the session is deleted one. Also, do I understand correctly that the options would apply only to > files module? If so, why they under session.* and not session.files.* or > something to emphasize that if you're not using files module it doesn't > do anything? No. It's applicable to all save handlers. files save handler is default save handler and there were comments that want separate implementation for files. That's the reason why there is such voting option. files and files_ext would be identical code except the code supports proposed options. I would like to have single code for easier maintenace. IMHO. Thank you for the comment. I hope everyone understands idea behind this RFC. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net