Hi Stephen,
On Wed, Oct 19, 2016 at 12:18 PM, Stephen Reay <php-li...@koalephant.com> wrote:
> I still have an issue with that. I believe the correct behaviour here is
> (assuming the `replace` argument to header() is honoured) what you’re seeing.
> Yes, it might be *unexpected* for new users, but its also *expected* by
> millions of current users/projects.
>
> I would suggest perhaps a warning on the header() docs page, and perhaps an
> example to avoid the issue on the Session handling page.
>
> Leaving it as-is, with improved docs means all functionality is *possible*
> with the right arguments.
>
> Changing to your proposal means advanced use-cases are *impossible* with any
> arguments.
>
>
> I realise you’re trying to remove WTF cases, but I don’t think removing
> advanced capabilities is the way to do that.
Yes. Even framework developer(?) seems to have current behavior.
In general, users shouldn't touch session ID. In case of user really
want to modify session ID cookie, following could be done.
<?php
ob_start();
session_start();
header_remove('Set-Cookie');
header('Set-Cookie: PHPSESSID=xxxx something');
?>
Make header_remove() able to delete 'Set-Cookie' header. (Current behavior)
Make header() able to send 'Set-Cookie' header. (Current behavior, but
not remove session ID cookie)
This allows users to send arbitrary session ID cookie when it is
needed really needed, while avoiding accidental session ID cookie
removal.
What do you think?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
