Web lists-archives.com

[PHP] BC break in 7.2 caused by undocumented and unauthorised change




I have just upgraded from 7.1.11 to 7.2.5 and have encountered a BC break due to a change in the behaviour of the session_name() function. I have been using this function in my code since 2003 and it has always performed as documented.

When I now run the session_name() function it fails with the message “Cannot change session name when session is active”. This is a break with the previous behaviour. The documentation clearly states “Get and/or set the current session name” which means that this function can be used in three ways:
•    to get the current session name
•    to set the session name to something else
•    to both get AND set the name at the same time

In my application I allow a user to create multiple browser windows so that they can view different parts of the application in different windows. This is done by first creating a clone of the current window in a new window, then starting a new session in one of the windows using code like this:
if ($_GET['action'] == 'newsession') {
   $session_name = getNewSessionName();  // user-defined function
   session_name($session_name);
   session_regenerate_id();
header('Location: ' ….); // restart script to use new session name and id
   exit;
}

The change implemented in 7.2 breaks this behaviour and breaks my code. Before I reported this as a bug I search the bug database and found https://bugs.php.net/bug.php?id=75650 which declared this change in behaviour as “not a bug”. My usage is clearly different, so I reported this as a new bug in https://bugs.php.net/bug.php?id=76358. Again the responder replied “this is not a bug” with a long list of lame excuses which boiled down to the fact that someone had reviewed the behaviour, didn’t think that it should work that way, and decided arbitrarily to change it without further ado.

The lamest excuse came from requinix@xxxxxxx who said: “It's clear to me from the current and past implementations that session_name() was never meant to alter the current session's name.”

How is it possible to reach such a conclusion when the documentation clearly states: “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.” Notice the use of the word “and”.

I raised the point that this BC break was never the subject of an RFC to which he replied: “Not all changes to PHP require an RFC”.

I raised the point that no change to session_name was ever discussed and voted upon in the internals list to which he replied: “This one was mentioned on the internals list by @yohgaki in mid October 2016 ("Fixing insane session_start() behaviors")”.

I checked this thread, but there was no mention of session_name, and certainly no mention of any change in behaviour that would cause a BC break.

I raised the point that no changes to session_name, or the fact that the change would cause a BC break, ever appeared in any PHP change logs or documentation, to which he replied that it appeared in a GitHub conversation. This to me is irrelevant as it never appeared in any official conversations on the php.internals list.

This whole episode raises serious doubts about the future of PHP if someone is allowed to make a change to the language, especially a change which causes a BC break, without following the correct procedures, namely propose, discuss, then vote. If anyone can make an arbitrary change to the language without peer review just because they think it should work in a different way then this could lead to more and more BC breaks which could then make the language unreliable and unusable for the army of application developers who have made the language as popular as it now is.

I urge the leaders of the internals group to review this serious breach of procedure and takes the necessary steps to ensure that it never happens again.

Tony Marston

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php