Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99887
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 74.125.83.51 cause and error)
MIME-Version: 1.0
In-Reply-To: <64.32.02884.7983D695@pb1.pair.com>
References: <64.32.02884.7983D695@pb1.pair.com>
Date: Tue, 18 Jul 2017 12:08:10 +0200
Message-ID: <CA+kxMuS9xgkCC-Cwh7Ems+UVsFd8aLrGoW+yZYx+aRCAXSv5bw@mail.gmail.com>
To: Andreas Treichel <gmblar@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] http_cookie_set and http_cookie_remove
From: danack@basereality.com (Dan Ackroyd)

On 18 July 2017 at 00:22, Andreas Treichel <gmblar@gmail.com> wrote:
> Hi,
>
> i want some feedback, about the following idea before i write a rfc.
>
> ... Most of them
> are optional and extensions (e.g. same-site) make it even more messy.


Two thoughts:

i) Cookie functions are easily done in userland.

ii) Adding more stuff to an already complicated thing isn't the way to
make it simple.

Or, to repeat myself: http://news.php.net/php.internals/90940


> The problem is that you're trying to build on a foundation of sand.
> The session handling works but is incredibly fragile.
>
> Or to put it more colloquially this is a "how to get to Dublin
> problem". To get to having a more secure and reliable session
> handling, we need to start from some where else, not just keep
> building on top of the current session handler code.
>
> To me, there are two good ways to proceed:
>
> i) Develop a new session extension, that doesn't depend on magic
> behaviour of globals and leave the current session handler as it is.
> The new session extension could be shipped as a 'work in progress' when
> it's good enough, before PHP 8. Then when it's stable, we could figure
> out how to transition users from the old extension.

> ii) Develop a session handler in userland code only. PHP is powerful
> enough to support this. Although obviously there are big benefits to
> shipping a session handler with PHP, I don't see any need for it to be
> done internally other than we don't currently have a way of shipping
> userland code with an extension. I'm hoping that before PHP 8, the
> ability to ship PHP code as part of extensions would be in place.


cheers
Dan
Ack