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