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
