Hi Andrey,
On Thu, Mar 13, 2014 at 7:36 PM, Andrey Andreev <[email protected]> wrote:
> > The _proper_ solution, would be to keep a timestamp stored with each
> session. kind of a last-modified timestamp. (expiry does work off last
> modification, right?). Anyhow, the trick is to check at session_start
> whether that timestamp plus whatever session.expire is set at, already is
> in the past - and when that happens, destroy the one session on storage and
> act as if it hadn't been found.
>
> Such a timestamp already exists, you can't implement sessions without
> one because there would be no way to know when a session have expired.
> For the files handler, it's filemtime() (afaik) and the behavior that
> you described is probably already in use (I see no reason not to).
>
Time stamp exists. It's correct partially.
The time stamp is not usable for HTTP session manager to manage session
properly. We may have new API that gets time stamp of session data, but it
would require large overhead. i.e. Need additional API call to get time
stamp = additional query to session storage. The overhead cannot be ignored.
The proper way to get and set the time stamp is "get/set time stamp" when
"store/retrieve session data". This way, there would not be overhead. User
may implement in their script, but it's a session manager task to begin
with.
>
> However, that's not in the scope of GC.
>
Managing time stamp is the main task of session GC, isn't it?
>
> > a GC is only needed to clean up sessions that are never requested again
> - and for that I fully agree that a separate - e.g. cron driven - "GC now"
> job would be best (not affecting latency of running frontent requests too
> much).
>
> ^ That is what a garbage collector is, indeed. :)
>
> On Thu, Mar 13, 2014 at 11:22 AM, Pierre Joye <[email protected]>
> wrote:
> > On Thu, Mar 13, 2014 at 8:45 AM, Yasuo Ohgaki <[email protected]>
> wrote:
> >
> >> It may be good idea to write a new save handler interface while keeping
> >> older one.
> >
> >
> > It would really helpful to target a later versions, maybe 6 and see
> > what we can do while minimizing the impact in userlands (whether or
> > not custom session handlers are implemented).
> >
> > But all the discussions and RFCs about basically the same needs have
> > been very confusing.
> >
> > What do you think? Is it something you could consider?
>
> I am deffinately a proponent of that. I already mentioned earlier that
> I have some ideas ... this is one of them.
>
> However, while Yasuo seems to always be keen on creating RFCs
> immediately, I'd rather focus on the existing ones that are session
> related:
You are the one who said there should be RFCs ;)
There are RFCs because I'm trying to change existing behaviors rather than
simple bug fixes.
Anyway, this was discussion of committed patch. It has much higher priority
than not implemented RFC, I suppose. I still think there should be GC
function. Programmers should control GC and there should be session
function for it rather than INI tweak.
https://wiki.php.net/rfc/secure-session-options-by-default
> https://wiki.php.net/rfc/session_regenerate_id
>
> 5.6 is really close and this is important stuff that was supposed to
> go in, but has not had updates recently and lagged behind.
> Changes for future versions can wait a few days/weeks ...
It's better to write something so that it would be forgotten.
I forgot to update session_regenerate_id RFC since it became part of other
RFC. I'll update it soon.
Regards,
--
Yasuo Ohgaki
[email protected]