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
