Re: http_cookie_set and http_cookie_remove

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