Bs Php wrote: > From: [EMAIL PROTECTED] > Operating system: Win 2k > PHP version: 4.1.0 > PHP Bug Type: Session related > Bug description: session.gc_maxlifetime does not work (Reopen Bug ID #3793) > > Befor going into the bug-report an importent question: > session.gc_maxlifetime documented as a lifetime messured in *seconds* with > default = 1440 > 1440s = 24min. hmm.... 24min ?? > Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time > AND 24 relates more to 24h! So is it realy *seconds* ?! > ---
It's in sec. and explained in php.ini-recommended and php.ini-dist :) If session life time is too long, bad users will easily perform DoS attack, also. > The Bug: > As reported in Bug ID #3793 (from [EMAIL PROTECTED]) following still > happens (taken from [EMAIL PROTECTED], 2000-12-07 and veryfied by > [EMAIL PROTECTED], 2001-11-25): > 1) "session.gc_maxlifetime" does not work - I set this to 60 sec, but I can > read values from the session even when time expired. (I start the session > and then I wait > more than 60 sec before calling other script) That's true. I might add the same feature as I did in pgsql session save handler. This breaks some sites for sure. We need discussion for this. > > 2) When I set "session.gc_probability = 100" in php.ini, ALL other session > files are deleted (only one session can be used at the time - if 2 clients > are connected to > server, the second client deletes session of the first client, etc.). . Hmm. I don't use files handler/Windows. Is this true for UNIX like OS, also? > My Comment: > To (1): This may be intended when using cookies! Because if > session.cookie_lifetime is =0 (until browser is restarted) finding a valid > SID in the cookie may prevent the gc from destroying the session data. (The > doc leves this open). > > To (2): For testing I've set "session.gc_probability = 50" but the effect > is the same. As soon as the gc runs, all other session-files are deleted. > gc_maxlifetime has no influance. > > [EMAIL PROTECTED] wrote that it may have to do with 'atime' and I would think > so too. I would consider to use 'mtime' (maybe as fallback). Even the > PHP-manual makes restriktions to 'atime': "Some Unix filesystems can be > mounted with atime updates disabled to increase the performance." I think mtime should be used instead of atime. Moving GC to RSHUTDOWN will fix your problem :) if we come up with agreement on this, it may be changed. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
