> 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'
8 matches
Mail list logo