Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73120 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77216 invoked from network); 13 Mar 2014 19:32:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2014 19:32:58 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.215.54 mail-la0-f54.google.com Received: from [209.85.215.54] ([209.85.215.54:45979] helo=mail-la0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 42/15-47923-8E702235 for ; Thu, 13 Mar 2014 14:32:57 -0500 Received: by mail-la0-f54.google.com with SMTP id mc6so1064747lab.27 for ; Thu, 13 Mar 2014 12:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=a473WH4071Js92OnEm5EbSpeX7xPqFEo/4n65cPhxkI=; b=JvVHOlkRxXJGjzpK/3N7KCJScpBu5mKzgdmHPEWjuIOxjYYUhCUEetL+brHaAsApKn lYBZ18vPBSK788Qg+Vc0p/fbHwdCUvL31lKXTRPCEqpCuECyPSYs54PPQp1GOlXE358k qvHgFXg3FKleUOVUGrvBpA495ErNr0gO+BKGXUhqfTqUwXN2d+VP2RCePz4/z9oaduGY kR5OAbXCoX5VLqBksyO4rzMJAZwXbnUqc2MsVqE2kjdd5dZtLhsIPtbb5bQ+Mgo59lzd r3fX21uQswGAzGUUaUzi+56bx5gYymJH711EeQtPQe+EZZBPYDnSLvmafa28bofic2wO QTmg== X-Received: by 10.112.173.6 with SMTP id bg6mr2310711lbc.17.1394739173533; Thu, 13 Mar 2014 12:32:53 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.205.73 with HTTP; Thu, 13 Mar 2014 12:32:13 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Mar 2014 04:32:13 +0900 X-Google-Sender-Auth: KE2cMpDBUN3QrQUVsMonhpEeqUk Message-ID: To: Andrey Andreev Cc: Pierre Joye , Patrick Schaaf , internals Content-Type: multipart/alternative; boundary=001a11c239befe2dc104f482042c Subject: Re: [PHP-DEV] Re: Revert session_serializer_name(), session_gc() From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11c239befe2dc104f482042c Content-Type: text/plain; charset=UTF-8 Hi Andrey, On Thu, Mar 13, 2014 at 7:36 PM, Andrey Andreev 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 > wrote: > > On Thu, Mar 13, 2014 at 8:45 AM, Yasuo Ohgaki > 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 yohgaki@ohgaki.net --001a11c239befe2dc104f482042c--