Hi Stephen,
On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay <[email protected]> wrote:
> The *only* solution that retains full control for the developer, is no
> change. Any “magic” about “untouchable” cookie headers (e.g. forcing the
> session cookie header after userland cookie headers) takes away options for
> the developer.
My cookie*() functions proposal allows developers to remove header by
cookie_remove() and can send any cookie header by cookie_custom().
Therefore, developers have full control if they have to.
The only pain is that users may have to use cookie*() functions if we
disallow header('Set-Cookie') which will be a vote option. If there is
fully functional cookie*() functions, it will mitigate wrong
header('Set-Cookie') usage regardless of the vote result, hopefully.
Regards,
--
Yasuo Ohgaki
[email protected]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php