Hi Tony,
This is a support list for PHP questions and help; the audience mostly
external to the PHP project itself.
Since your message is clearly meant for consumption by "the internals
group", it should instead have been sent to the internals mailing list at
internals@xxxxxxxxxxxxx
Thanks,
Peter
On 23 May 2018 at 15:50, Tony Marston <TonyMarston@xxxxxxxxxxx> wrote:
> 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
>
>
