Doc #76358 [Ver]: Cannot change session name when session is active

Edit report at https://bugs.php.net/bug.php?id=76358&edit=1 ID: 76358 User updated by: tony at marston-home dot demon dot co dot uk Reported by: tony at marston-home dot demon dot co dot uk Summary: Cannot change session name when session is active Status: Verified Type: Documentation Problem Package: Session related Operating System: Windows 10 PHP Version: 7.2.5 Block user comment: N Private report: N New Comment: > It did not change the session name, though. Yes it did. I stated using "session_name('newname')" as early as 2003 (and documented on my website in 2005). It kept on doing just that until it was broken in 7.2. > The documentation also clearly states: | Thus, you need to call session_name() for every request (and | before session_start() or session_register() are called). That means that you must follow a call to session_name() with a call to session_start() before the new name can take effect. It *DOES NOT* mean that you cannot call session_name('newname') while the current session is still active. > Since session_name('foo') does not update the name of the session > if it has already been started, it *must* not return the name of > the old session according to the documentation. The fact that "$oldname = session_name('newname')" did not work AS DOCUMENTED was a bug. The description for this function CLEARLY states the following: "session_name() returns the name of the current session. If name is given, session_name() will update the session name *AND* return the old session name. That clearly states that you should be able to both return the name of the current session *AND* set a new session name at the same time. It was *NEVER* necessary to close the current session before changing its name. Previous Comments: ------------------------------------------------------------------------ [2018-05-24 13:01:21] cmb@php.net > I expect session_name() to do what it has been doing for the > past 15 years, that is to return the existing session name while > assigning a new one. It did not change the session name, though. > The documentation clearly states "Get and/or set the current > session name", and the "and/or" indicates that it should be able > to do both at the same time. The documentation also clearly states: | Thus, you need to call session_name() for every request (and | before session_start() or session_register() are called). And: | If name is given and function updates the session name, name of | the old session is returned. Since session_name('foo') does not update the name of the session if it has already been started, it *must* not return the name of the old session according to the documentation. ------------------------------------------------------------------------ [2018-05-23 11:44:09] notasockpuppet at atotallyrealdomain dot com I am HORRIFIED to find that a change was made that was not personally signed off by Toby. I will not be using PHP any more, this is the final straw. I can cope with the weird names and inconsistent APIs and segfaults and projects possessed by demonic forces, but I WILL NOT support a community that does not respect such wise people as Tiny. ------------------------------------------------------------------------ [2018-05-23 08:27:33] tony at marston-home dot demon dot co dot uk I have checked that discussion, and NOWHERE does it mention a change in behaviour for session_name() that would cause a BC break. This was never identified, discussed, or voted upon, therefore I consider it to be an unauthorised change. Changing the behaviour back to what it originally was, and AS DOCUMENTED for the past 20 years, will not cause any BC breaks, so your "fix" for a problem which did not exist in the first place should be reverted. ------------------------------------------------------------------------ [2018-05-23 06:43:48] a at b dot c dot de >Not all changes to PHP require an RFC. This one was mentioned on the internals list by @yohgaki >in mid October 2016 ("Fixing insane session_start() behaviors") and the discussion lasted >for a couple days without any dissenting opinions offered. During the discussion on the internals list and on github, @yohgaki did mention that he _should_ have written an RFC on the subject, but never got around to doing so. Perhaps he could write one ex post facto to consolidate the whys and wherefores of this change and serve as a future citation reference. ------------------------------------------------------------------------ [2018-05-22 11:42:45] tony at marston-home dot demon dot co dot uk How can reverting code which caused a BC break be a BC in itself? What existing scripts which may have been modified to get around the BC break which you introduced would be broken if the original AND DOCUMENTED behaviour were to be reinstated? If the userland fix to get around this BC break is to insert a call to session_write_close() before the call to session_name() then what harm would it cause? It would just mean that the call to session_write_close() would be redundant. It would certainly not cause an error. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76358 -- Edit this bug report at https://bugs.php.net/bug.php?id=76358&edit=1