Re: [PHP] Re: session.gc_maxlifetime
> php not but perhaps the client its not clear and commonly defined what > clients do with cookies on reconnect and stuff or long idle times. Maybe not, but I'd be really surprised. An HTTP client is supposed to decide whether to send a cookie by looking at the domain name and path of the URL it's requesting. These things are at a totally different layer from IP addresses -- and even if they weren't, in most cases I would think a browser is going to be ignorant of public IP address changes because it's going to be behind a NAT device. > I would expect as source the new browsers where more and more users use > subwindows to have concurrent sessions, does anybody know how they handle ip > changes? I'm not. What specific situation do you have in mind in which a browser would even be aware of an IP change on the client side? Maybe there are common cases I'm not thinking of. Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: session.gc_maxlifetime
php not but perhaps the client its not clear and commonly defined what clients do with cookies on reconnect and stuff or long idle times. I would expect as source the new browsers where more and more users use subwindows to have concurrent sessions, does anybody know how they handle ip changes? I'm not. these things are new and that would fit that the problem is new as well. "bdunlap" wrote in message news:7997e80e0909240851t7f0a2189u4540a09546a85...@mail.gmail.com... > > it could be ip address changes. interesting thought. > > As far as I'm aware, PHP session-management doesn't care about source > IP, out-of-the-box -- your app would have to be coded to care. Plus I > suspect you would have started seeing the problem a long time ago, if > changing source IPs were the cause. > > Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: session.gc_maxlifetime
> it could be ip address changes. interesting thought. As far as I'm aware, PHP session-management doesn't care about source IP, out-of-the-box -- your app would have to be coded to care. Plus I suspect you would have started seeing the problem a long time ago, if changing source IPs were the cause. Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: session.gc_maxlifetime
it could be ip address changes. interesting thought. i think i should add some special logging. it's a dedicated freebsd server with one app. On 9/23/09 6:43 PM, "Ralph Deffke" wrote: > finaly we went with a custom cooky handling, however the customers > requirements where two days. > > if u are shure that the server is still the same hardware like it has been 6 > years ago then it might be some client stuff, however if there are other > applications, pages running (virtual servers) then it would still be to > consider. mamory and resource management is deep os. again I wouldn't trust > for that amount of session livetime. > > I dont think, putting it down to three hours would help much. > > and of course, it could be client side also. Can't you figure out the > clients? > and keep in mind that a lot of people connect to UMTS rigzt now, these > systems deconnect on idle lines and reconect without the users even know it. > Also a lot of lines change IP address at midnihgt. > > cheers > ralph_def...@yahoo.de > > "Tom Worster" wrote in message > news:c6e00521.12d98%...@thefsb.org... >> there's a need for long timeouts in this app but could perhaps be reduced >> from 6 to 3 hours. >> >> the sessions are cookie based using php's 'file' handler and >> session.cookie_lifetime=0. the server appears to have plenty of free > memory >> and appears not to have swapped in nearly a year of uptime. load averages >> indicate a pretty quiet server. there are currently 170 kbyte total in 90 >> serialized session files which is typical and not a memory load. the >> distribution of modification times doesn't indicate heavy activity: ~20 >> files in the last 15 minutes and 35 in the last hour. >> >> so i think the os can handle this. plus the app ran for 6 years before >> anyone reported being prematurely logged off. i'm looking for other >> possibilities: odd browser behavior, network trouble, ... >> >> >> are there any browsers that have configurable cookie handling policy such >> that they time out a cookie? >> >> one web site i use displays this curious message: "For your protection, >> sessions are open for a limited period of time on our website. Please >> sign-on again. NOTE: Your browser may also limit secure connection time, > and >> automatically log you out independent of our timeout procedure." >> >> that could be referring to browsers timing out an ssl connection. or > perhaps >> the cookie? >> >> >> btw: when you said in your email you wouldn't trust a long gc_maxlifetime, >> and you would only use a cookie-based solution for long session. did you >> mean that you wouldn't trust php's cookie-based session handler? and you >> would use a custom handler instead? >> >> >> On 9/22/09 4:46 PM, "Ralph Deffke" wrote: >> >>> Hi Tom, >>> >>> in sometimes 2001 I did have incidences with those things, and as I > remember >>> over the past years there where some trouble with operating systems and >>> stuff. This part is very deep inside the os. I would expect that this is >>> still to consider. I also would check, if this occurs on very busy/low >>> memory server. >>> >>> If I would programm the garbage collection clean up part, and if the > server >>> is about to run out of memory, I would kill sessions being longer time > idle >>> even when they are not yet as old as it is set in the gc_maxlifetime. > This >>> would be far better then shutting down the whole server just because > there a >>> 100 of idle sessions waiting to get used again. >>> >>> as u mention a maxlivetime of 6h I would bet, that this is the problem. > I >>> would not trust such a long lifetime at all. >>> >>> If sessions have to be active such a long time, I would see only cooky > based >>> solutions >>> >>> let me know, what u did investigate on this. >>> >>> ralph_def...@yahoo.de >>> >>> >>> "Tom Worster" wrote in message >>> news:c6deae55.12cae%...@thefsb.org... thank you, Ralph! i'm going to be bold and assume that tom at punkave dot com is right >>> despite that the report was discarded. i got a complaint from a client about some users reporting being logged >>> out with rather short periods of inactivity. but session.gc_maxlifetime is > set to 6 hours so i don't think that's the source of the problem. On 9/22/09 4:17 PM, "Ralph Deffke" wrote: > Hi Tom, > > i did find this in the bug reports, its pretty new and should be an >>> answer. > > http://news.php.net/php.doc.bugs/2653 > > ralph_def...@yahoo.de > > > "Tom Worster" wrote in message > news:c6de9eee.12c8d%...@thefsb.org... >> i'm not 100% sure what the manual means when it says... >> >> session.gc_maxlifetime integer >> session.gc_maxlifetime specifies the number of seconds after which > data > will >> be seen as 'garbage' and cleaned up. Garbage collection occurs during >> session start. >> >> what event exactl
Re: [PHP] Re: session.gc_maxlifetime
finaly we went with a custom cooky handling, however the customers requirements where two days. if u are shure that the server is still the same hardware like it has been 6 years ago then it might be some client stuff, however if there are other applications, pages running (virtual servers) then it would still be to consider. mamory and resource management is deep os. again I wouldn't trust for that amount of session livetime. I dont think, putting it down to three hours would help much. and of course, it could be client side also. Can't you figure out the clients? and keep in mind that a lot of people connect to UMTS rigzt now, these systems deconnect on idle lines and reconect without the users even know it. Also a lot of lines change IP address at midnihgt. cheers ralph_def...@yahoo.de "Tom Worster" wrote in message news:c6e00521.12d98%...@thefsb.org... > there's a need for long timeouts in this app but could perhaps be reduced > from 6 to 3 hours. > > the sessions are cookie based using php's 'file' handler and > session.cookie_lifetime=0. the server appears to have plenty of free memory > and appears not to have swapped in nearly a year of uptime. load averages > indicate a pretty quiet server. there are currently 170 kbyte total in 90 > serialized session files which is typical and not a memory load. the > distribution of modification times doesn't indicate heavy activity: ~20 > files in the last 15 minutes and 35 in the last hour. > > so i think the os can handle this. plus the app ran for 6 years before > anyone reported being prematurely logged off. i'm looking for other > possibilities: odd browser behavior, network trouble, ... > > > are there any browsers that have configurable cookie handling policy such > that they time out a cookie? > > one web site i use displays this curious message: "For your protection, > sessions are open for a limited period of time on our website. Please > sign-on again. NOTE: Your browser may also limit secure connection time, and > automatically log you out independent of our timeout procedure." > > that could be referring to browsers timing out an ssl connection. or perhaps > the cookie? > > > btw: when you said in your email you wouldn't trust a long gc_maxlifetime, > and you would only use a cookie-based solution for long session. did you > mean that you wouldn't trust php's cookie-based session handler? and you > would use a custom handler instead? > > > On 9/22/09 4:46 PM, "Ralph Deffke" wrote: > > > Hi Tom, > > > > in sometimes 2001 I did have incidences with those things, and as I remember > > over the past years there where some trouble with operating systems and > > stuff. This part is very deep inside the os. I would expect that this is > > still to consider. I also would check, if this occurs on very busy/low > > memory server. > > > > If I would programm the garbage collection clean up part, and if the server > > is about to run out of memory, I would kill sessions being longer time idle > > even when they are not yet as old as it is set in the gc_maxlifetime. This > > would be far better then shutting down the whole server just because there a > > 100 of idle sessions waiting to get used again. > > > > as u mention a maxlivetime of 6h I would bet, that this is the problem. I > > would not trust such a long lifetime at all. > > > > If sessions have to be active such a long time, I would see only cooky based > > solutions > > > > let me know, what u did investigate on this. > > > > ralph_def...@yahoo.de > > > > > > "Tom Worster" wrote in message > > news:c6deae55.12cae%...@thefsb.org... > >> thank you, Ralph! > >> > >> i'm going to be bold and assume that tom at punkave dot com is right > > despite > >> that the report was discarded. > >> > >> i got a complaint from a client about some users reporting being logged > > out > >> with rather short periods of inactivity. but session.gc_maxlifetime is set > >> to 6 hours so i don't think that's the source of the problem. > >> > >> > >> On 9/22/09 4:17 PM, "Ralph Deffke" wrote: > >> > >>> Hi Tom, > >>> > >>> i did find this in the bug reports, its pretty new and should be an > > answer. > >>> > >>> http://news.php.net/php.doc.bugs/2653 > >>> > >>> ralph_def...@yahoo.de > >>> > >>> > >>> "Tom Worster" wrote in message > >>> news:c6de9eee.12c8d%...@thefsb.org... > i'm not 100% sure what the manual means when it says... > > session.gc_maxlifetime integer > session.gc_maxlifetime specifies the number of seconds after which data > >>> will > be seen as 'garbage' and cleaned up. Garbage collection occurs during > session start. > > what event exactly does the "after which" here refer to? > > i'd like to think that it means that a session is eligible for gc no > >>> sooner > than session.gc_maxlifetime seconds after the most recent access (read > > or > write) to that session. but it seems dangerously presumptuous to assume > >>> that > this is
Re: [PHP] Re: session.gc_maxlifetime
there's a need for long timeouts in this app but could perhaps be reduced from 6 to 3 hours. the sessions are cookie based using php's 'file' handler and session.cookie_lifetime=0. the server appears to have plenty of free memory and appears not to have swapped in nearly a year of uptime. load averages indicate a pretty quiet server. there are currently 170 kbyte total in 90 serialized session files which is typical and not a memory load. the distribution of modification times doesn't indicate heavy activity: ~20 files in the last 15 minutes and 35 in the last hour. so i think the os can handle this. plus the app ran for 6 years before anyone reported being prematurely logged off. i'm looking for other possibilities: odd browser behavior, network trouble, ... are there any browsers that have configurable cookie handling policy such that they time out a cookie? one web site i use displays this curious message: "For your protection, sessions are open for a limited period of time on our website. Please sign-on again. NOTE: Your browser may also limit secure connection time, and automatically log you out independent of our timeout procedure." that could be referring to browsers timing out an ssl connection. or perhaps the cookie? btw: when you said in your email you wouldn't trust a long gc_maxlifetime, and you would only use a cookie-based solution for long session. did you mean that you wouldn't trust php's cookie-based session handler? and you would use a custom handler instead? On 9/22/09 4:46 PM, "Ralph Deffke" wrote: > Hi Tom, > > in sometimes 2001 I did have incidences with those things, and as I remember > over the past years there where some trouble with operating systems and > stuff. This part is very deep inside the os. I would expect that this is > still to consider. I also would check, if this occurs on very busy/low > memory server. > > If I would programm the garbage collection clean up part, and if the server > is about to run out of memory, I would kill sessions being longer time idle > even when they are not yet as old as it is set in the gc_maxlifetime. This > would be far better then shutting down the whole server just because there a > 100 of idle sessions waiting to get used again. > > as u mention a maxlivetime of 6h I would bet, that this is the problem. I > would not trust such a long lifetime at all. > > If sessions have to be active such a long time, I would see only cooky based > solutions > > let me know, what u did investigate on this. > > ralph_def...@yahoo.de > > > "Tom Worster" wrote in message > news:c6deae55.12cae%...@thefsb.org... >> thank you, Ralph! >> >> i'm going to be bold and assume that tom at punkave dot com is right > despite >> that the report was discarded. >> >> i got a complaint from a client about some users reporting being logged > out >> with rather short periods of inactivity. but session.gc_maxlifetime is set >> to 6 hours so i don't think that's the source of the problem. >> >> >> On 9/22/09 4:17 PM, "Ralph Deffke" wrote: >> >>> Hi Tom, >>> >>> i did find this in the bug reports, its pretty new and should be an > answer. >>> >>> http://news.php.net/php.doc.bugs/2653 >>> >>> ralph_def...@yahoo.de >>> >>> >>> "Tom Worster" wrote in message >>> news:c6de9eee.12c8d%...@thefsb.org... i'm not 100% sure what the manual means when it says... session.gc_maxlifetime integer session.gc_maxlifetime specifies the number of seconds after which data >>> will be seen as 'garbage' and cleaned up. Garbage collection occurs during session start. what event exactly does the "after which" here refer to? i'd like to think that it means that a session is eligible for gc no >>> sooner than session.gc_maxlifetime seconds after the most recent access (read > or write) to that session. but it seems dangerously presumptuous to assume >>> that this is the case. what do you take it to mean? >>> >>> >> >> > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: session.gc_maxlifetime
Hi Tom, in sometimes 2001 I did have incidences with those things, and as I remember over the past years there where some trouble with operating systems and stuff. This part is very deep inside the os. I would expect that this is still to consider. I also would check, if this occurs on very busy/low memory server. If I would programm the garbage collection clean up part, and if the server is about to run out of memory, I would kill sessions being longer time idle even when they are not yet as old as it is set in the gc_maxlifetime. This would be far better then shutting down the whole server just because there a 100 of idle sessions waiting to get used again. as u mention a maxlivetime of 6h I would bet, that this is the problem. I would not trust such a long lifetime at all. If sessions have to be active such a long time, I would see only cooky based solutions let me know, what u did investigate on this. ralph_def...@yahoo.de "Tom Worster" wrote in message news:c6deae55.12cae%...@thefsb.org... > thank you, Ralph! > > i'm going to be bold and assume that tom at punkave dot com is right despite > that the report was discarded. > > i got a complaint from a client about some users reporting being logged out > with rather short periods of inactivity. but session.gc_maxlifetime is set > to 6 hours so i don't think that's the source of the problem. > > > On 9/22/09 4:17 PM, "Ralph Deffke" wrote: > > > Hi Tom, > > > > i did find this in the bug reports, its pretty new and should be an answer. > > > > http://news.php.net/php.doc.bugs/2653 > > > > ralph_def...@yahoo.de > > > > > > "Tom Worster" wrote in message > > news:c6de9eee.12c8d%...@thefsb.org... > >> i'm not 100% sure what the manual means when it says... > >> > >> session.gc_maxlifetime integer > >> session.gc_maxlifetime specifies the number of seconds after which data > > will > >> be seen as 'garbage' and cleaned up. Garbage collection occurs during > >> session start. > >> > >> what event exactly does the "after which" here refer to? > >> > >> i'd like to think that it means that a session is eligible for gc no > > sooner > >> than session.gc_maxlifetime seconds after the most recent access (read or > >> write) to that session. but it seems dangerously presumptuous to assume > > that > >> this is the case. > >> > >> what do you take it to mean? > >> > >> > > > > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: session.gc_maxlifetime
thank you, Ralph! i'm going to be bold and assume that tom at punkave dot com is right despite that the report was discarded. i got a complaint from a client about some users reporting being logged out with rather short periods of inactivity. but session.gc_maxlifetime is set to 6 hours so i don't think that's the source of the problem. On 9/22/09 4:17 PM, "Ralph Deffke" wrote: > Hi Tom, > > i did find this in the bug reports, its pretty new and should be an answer. > > http://news.php.net/php.doc.bugs/2653 > > ralph_def...@yahoo.de > > > "Tom Worster" wrote in message > news:c6de9eee.12c8d%...@thefsb.org... >> i'm not 100% sure what the manual means when it says... >> >> session.gc_maxlifetime integer >> session.gc_maxlifetime specifies the number of seconds after which data > will >> be seen as 'garbage' and cleaned up. Garbage collection occurs during >> session start. >> >> what event exactly does the "after which" here refer to? >> >> i'd like to think that it means that a session is eligible for gc no > sooner >> than session.gc_maxlifetime seconds after the most recent access (read or >> write) to that session. but it seems dangerously presumptuous to assume > that >> this is the case. >> >> what do you take it to mean? >> >> > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: session.gc_maxlifetime
I forgot to mention, that this doesn't mean, you can not read data after this timeout or that a session does ALWAYS die after this timeout. I would assume, that the server has to have a reason to run garbage clean up. If the server is not running a clean up, I would expect the session would excist longer for access. ralph_def...@yahoo.de "Tom Worster" wrote in message news:c6de9eee.12c8d%...@thefsb.org... > i'm not 100% sure what the manual means when it says... > > session.gc_maxlifetime integer > session.gc_maxlifetime specifies the number of seconds after which data will > be seen as 'garbage' and cleaned up. Garbage collection occurs during > session start. > > what event exactly does the "after which" here refer to? > > i'd like to think that it means that a session is eligible for gc no sooner > than session.gc_maxlifetime seconds after the most recent access (read or > write) to that session. but it seems dangerously presumptuous to assume that > this is the case. > > what do you take it to mean? > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: session.gc_maxlifetime
Hi Tom, i did find this in the bug reports, its pretty new and should be an answer. http://news.php.net/php.doc.bugs/2653 ralph_def...@yahoo.de "Tom Worster" wrote in message news:c6de9eee.12c8d%...@thefsb.org... > i'm not 100% sure what the manual means when it says... > > session.gc_maxlifetime integer > session.gc_maxlifetime specifies the number of seconds after which data will > be seen as 'garbage' and cleaned up. Garbage collection occurs during > session start. > > what event exactly does the "after which" here refer to? > > i'd like to think that it means that a session is eligible for gc no sooner > than session.gc_maxlifetime seconds after the most recent access (read or > write) to that session. but it seems dangerously presumptuous to assume that > this is the case. > > what do you take it to mean? > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
