> 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
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'
> 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 caus
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
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 i
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 ave
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/l
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'
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
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_maxlife
10 matches
Mail list logo
