ID: 34588 Updated by: [EMAIL PROTECTED] Reported By: michael dot caplan at htc dot ca -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Debian PHP Version: 4.4.0 New Comment:
Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with <?php and ends with ?>, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Can you send in a reproduce script that consistently exhibits this behaviour? I can't reproduce this on my local system building from CVS. With a script the devs can tell if the problem is really with the session handling or with something else. Previous Comments: ------------------------------------------------------------------------ [2005-09-21 21:30:13] michael dot caplan at htc dot ca Description: ------------ I have a rather peculiar problem with session.gc_maxlifetime local settings not being respected under certain circumstances. In order to ensure that sessions created for our application would have a max lifetime longer than the default 24 minutes, we cranked session.gc_maxlifetime in an .htaccess file to 4 hours (local value). However, our sessions where still being clean up after 24 minutes. I validated through phpinfo() that it was actually picking up the local setting, which it was. I also noticed in my testing that if I reduced the session.gc_maxlifetime local value to less than the master value, my sessions would be cleaned up in accordance to the local value. When we changed the master value to 4 hours, we are no longer having our sessions cleaned up within 24 minutes. It appears that the local value of session.gc_maxlifetime is only being respected if it is less than that of the master value. The noted behaviour I beleive has to do with PHP internal session handling mechanism. I have no other oppertations touching session content. Also, the behaviour was noted at the file system level when another user is connecting with a different session ID resulting in other users sessions being cleaned up. So it is not an issue of a current user having his session invalidated through other means outside of garbage collection. BTW, we are using the file based session container ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=34588&edit=1
