Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92399
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaysM4jcdOzW9ZXzFD_XOgkxphTH_JC0__HEYTNeCniHw@mail.gmail.com>
References: <CAGa2bXb-jON8qZyje_ETckyO-KCmcbhTjcJt=NJZ1agAgzqMoQ@mail.gmail.com>
	<CAPhkiZx7zc1=1zyx=vJvZtr7x7OhktDFCHMK4GdOCD_DSqbKCg@mail.gmail.com>
	<CAGa2bXaZnsGnrKAAPmxHG+hut3+1=8bdOER--WrsXXowoiXu=A@mail.gmail.com>
	<CAPhkiZyHruaK9NM4C-4PcQ-2x4QK52Lv+JAyhLHoP=ufcufjWw@mail.gmail.com>
	<CAGa2bXb14ucv2PyHeVHMTcvUrqXD+QehqYHiBZtsqcXW1tgjXA@mail.gmail.com>
	<570D2F74.7060702@gmail.com>
	<CAGa2bXaysM4jcdOzW9ZXzFD_XOgkxphTH_JC0__HEYTNeCniHw@mail.gmail.com>
Date: Mon, 18 Apr 2016 11:12:46 +0300
Message-ID: <CAPhkiZxt--wdXcNVU4yDKxeJHqBhjECMUH65gyEzscHZQMy0Dg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0149c20cf9e69e0530bdecf1
Subject: Re: [PHP-DEV] [RFC][Discussion] Add session_gc()
From: narf@devilix.net (Andrey Andreev)

--089e0149c20cf9e69e0530bdecf1
Content-Type: text/plain; charset=UTF-8

Hi,

On Sat, Apr 16, 2016 at 12:15 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Stas,
>
> On Wed, Apr 13, 2016 at 2:25 AM, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
> >> Lack of proper API for required task is our problem. Misuse is not
> ours. IMHO.
> >
> > No, it is our problem. We can't just create whatever and throw it over
> > the fence. The properly designed API has to make correct use very easy
> > and incorrect use very hard. That's the point of designing the API, not
> > just giving people means to run random pieces of C code from PHP.
> >
> > With that in mind, the API should be designed so that misuse -
> > especially unintentional misuse - is hard. Not impossible - that we
> > can't do - but hard. It *is* our responsibility.
>
> I know there are different point views, but I'm against this POV.
>
> There _must_ be API that achieves well defined tasks. There are many APIs
> that do not do this, but I don't think this would be an excuse. There are
> many
> examples in security related APIs.
>

I don't believe anybody is questioning the need to introduce this new API.

What I am questioning is, at minimum, how it is documented. And that's
because you've explicitly stated this in your RFC:

> Document calling session_gc() periodically is the best practice.

If you want to document usage of this new API as the best practice, it
would be unfair to the users if you don't also document the caveats that
come with it:

 - That they should NOT e.g. put session_gc() at the top of their
front-controllers
 - That it is ONLY meant to be called by a regularly-executed cron script
 - That it WILL result in double GC calls if they don't turn off
probability-based behavior (and how to do that; based on my observations,
the vast majority of users don't know how GC is triggered at all)

Documenting these potential problems is the bare minimum to minimize
misusage, although I think it's a cop-out. IMO, there should be safe-guards
implemented into the function itself:

- Trigger warnings when session_gc() is called while gc_probability is not
0.
- To avoid re-activating expired sessions, trigger warnings when
session_gc() is called after session_start()

... and possibly skip GC execution in these cases.

Cheers,
Andrey.

--089e0149c20cf9e69e0530bdecf1--