Re: http_cookie_set and http_cookie_remove
| From: | Andrey Andreev | Date: | Tue, 18 Jul 2017 10:33:44 +0000 |
| Subject: | Re: http_cookie_set and http_cookie_remove | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-99890@lists.php.net to get a copy of this message | ||
Hi Dan,
On Tue, Jul 18, 2017 at 1:08 PM, Dan Ackroyd <danack@basereality.com> wrote:
> 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.
>
It's not that easy for somebody unfamiliar with RFC 6265, and in my
observations that's most people.
> 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.
>
I don't get this ... new functions are being proposed, not modifying
the already existing ones - this is one of the good ways you've
listed.
Cheers,
Andrey.