ID: 50066 User updated by: phpbug at reider dot net Reported By: phpbug at reider dot net Status: Bogus Bug Type: Session related Operating System: debian PHP Version: 5.3.1RC2 New Comment:
Johannes, Thanks for the update. It is true that it will be infrequent in practice because as you say users will clean each others sessions, but I would like to apply this very argument in favor of changing it - the latency problem will in practice not present itself in higher traffic scenarios. Meanwhile it does make a difference in low volume scenarios (of which development is a primary case). What we have now is that sessions appears active on a request made after a long idle period, but then appears inactive on the request immediately following. It is really unexpected and feels 'backwards'. I suggest that the latency (given the above premise that this only affects the low traffic scnario) is in fact the lesser evil, and changing it would make for more consistent behavior - it would work the same irrespective of random state changes occurring on the machine that are not really part of the user transaction. Previous Comments: ------------------------------------------------------------------------ [2009-11-03 19:47:39] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Removing the data before handling the request increases the latency till the user gets a response (as the session files are being deleted) and as you said there should be no practical effect with this as usually you have more than one user so they\'ll clean each others sessions. ------------------------------------------------------------------------ [2009-11-03 18:07:03] phpbug at reider dot net Description: ------------ sessions don't appear to expire when expected. for example: a logon request arrives and the app calls session_start() and stores authentication data in the session. session.gc_maxlifetime+n seconds later, a 2nd request arrives. The authentication data is loaded and the 2nd request is processed as if the session is active. A few seconds later a 3rd request arrives; in the 3rd request all the session data is gone, as if the session only just timed out even though the user requested immediately after the 2nd response. Apparently, php deserializes session data and does gc() (if it is to be done) afterwards; so in the 2nd request, the data is loaded into the session, *then* the files are removed. I expected that the 2nd, not 3rd request would have no session data Wouldn'tm it makeore sense to gc *before* loading the session data? That way, it would be the *2nd* request to perceive a session timeout, instead of the 3rd. Reproduce code: --------------- I have session.gc_probability=100 and session.gc_divisor=100 to run gc on each request. Expected result: ---------------- I expected that the 2nd, not 3rd request would have the session data not deserialized. While in practice it will usually be the case that the the gc will occur in a different users process, nevertheless, I suggest that if session_start() does a gc which results in the session data being removed, it should not also load it into the session. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=50066&edit=1
