Welcome! Log In Create A New Profile

Advanced

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

Posted by Tony Marston 
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@php.net 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
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@lists.php.net

Thanks,
Peter


On 23 May 2018 at 15:50, Tony Marston <[email protected]> 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@php.net 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
>
>
On 23.05.2018 at 17:03, Peter Cowburn wrote:

> 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@lists.php.net

From which Tony might still be blocked[1], though.

[1] <https://externals.io/message/101479#101528>;.

--
Christoph M. Becker

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
"Peter Cowburn" wrote in message
news:[email protected]om...
>
>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
>[email protected]
>
>Thanks,
>Peter
>
>
>On 23 May 2018 at 15:50, Tony Marston <[email protected]> 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@php.net 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
>>
>>

I would love to, but I have been banned from posting to that group because
certain people do not like me complaining about BC breaks. I would be
grateful if someone with access to that group could forward this post.

Thanks.

--
Tony Marston


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
""Christoph M. Becker"" wrote in message
news:[email protected]
>
>On 23.05.2018 at 17:03, Peter Cowburn wrote:
>
>> 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@lists.php.net
>
>From which Tony might still be blocked[1], though.
>
>[1] <https://externals.io/message/101479#101528>;.
>

If you read that post you will see that it was mostly complaining about the
person known as "rhsoft". All I did was argue AGAINST his viewpoint, yet I
was still banned in what I would call an arbitrary manner. Note that I say
"banned" and not "suspended" as I was not informed of what action was to be
taken against me, nor was I given a chance to explain myself.

--
Tony Marston


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On 23.05.2018 at 17:29, Tony Marston wrote:

> If you read that post you will see that it was mostly complaining about
> the person known as "rhsoft". All I did was argue AGAINST his viewpoint,
> yet I was still banned in what I would call an arbitrary manner. Note
> that I say "banned" and not "suspended" as I was not informed of what
> action was to be taken against me, nor was I given a chance to explain
> myself.

FTR: you have been repeately admonished for offending the mailing list
rules and netiquette by several people, for instance in
http://news.php.net/php.internals/100765. Even after it has suggested
to suspend your mailing list access, you have not shown insight or
regret, see <https://externals.io/message/101479#101501>;, for instance.

Wrt. the actual issue see my comment in https://bugs.php.net/76358.

--
Christoph M. Becker

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
If you bothered to read http://news.php.net/php.internals/100765 you would see that it merely asked me to calm down with my comments against rhsoft, which I did.

If you bothered to read <https://externals.io/message/101479#101501>; you would see that there is no properly documented code of conduct, so nobody could actually point to anything I said which broke any of these undocumented rules. Al that happened is that somebody did not like what I was saying and complained to a moderator, and I found myself banned from the list without any explanation and without warning. I was not told that I was going to be banned, it just happened. I was not suspended for a period of time, I was permanently banned. That just proves that the age old notion of free speech does not exist on the internals list.

Tony Marston

-----Original Message-----
From: Christoph M. Becker <[email protected]>
Sent: 24 May 2018 14:03
To: Tony Marston <[email protected]>; php-general@lists.php.net
Subject: Re: [PHP] BC break in 7.2 caused by undocumented and unauthorised change

On 23.05.2018 at 17:29, Tony Marston wrote:

> If you read that post you will see that it was mostly complaining
> about the person known as "rhsoft". All I did was argue AGAINST his
> viewpoint, yet I was still banned in what I would call an arbitrary
> manner. Note that I say "banned" and not "suspended" as I was not
> informed of what action was to be taken against me, nor was I given a
> chance to explain myself.

FTR: you have been repeately admonished for offending the mailing list rules and netiquette by several people, for instance in http://news.php.net/php.internals/100765. Even after it has suggested to suspend your mailing list access, you have not shown insight or regret, see <https://externals.io/message/101479#101501>;, for instance.

Wrt. the actual issue see my comment in https://bugs.php.net/76358.

--
Christoph M. Becker

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



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, May 24, 2018 at 03:01:18PM +0100, tony@marston-home.demon.co.uk wrote:

[snip]

> That just proves that the age old notion of free speech does not exist on the internals list.

I'm not involved in any of the current drama and I have no skin in this
game. But I do get tired of people who are called out for bad behavior
consistently claiming that some supposed right to free speech they think
they have has been trampled. Indeed, you do have an a priori right to
speak freely. But that "right" may be curtailed relative to the venue
involved. Realize that in order to speak as freely as you like, you may
have to devise your own platform from which to speak. Because people in
their own venues don't owe you the time of day when it comes to "free
speech".

--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Can you identify which of my posts violated the Code of Conduct for the
internals list? Can you even find a Code of Conduct? Being banned because I
consistently violated the code is one thing, but being banned just because
someone did not like what I had to say is something else entirely.

If you want to read the history of events then take a look at http://www dot
tonymarston dot net/php-mysql/on-being-banned.html

Tony Marston

-----Original Message-----
From: Paul M Foster <[email protected]>
Sent: 24 May 2018 16:55
To: php-general@lists.php.net
Subject: Re: [PHP] BC break in 7.2 caused by undocumented and unauthorised
change

On Thu, May 24, 2018 at 03:01:18PM +0100, tony@marston-home.demon.co.uk
wrote:

[snip]

> That just proves that the age old notion of free speech does not exist on
the internals list.

I'm not involved in any of the current drama and I have no skin in this
game. But I do get tired of people who are called out for bad behavior
consistently claiming that some supposed right to free speech they think
they have has been trampled. Indeed, you do have an a priori right to speak
freely. But that "right" may be curtailed relative to the venue involved.
Realize that in order to speak as freely as you like, you may have to devise
your own platform from which to speak. Because people in their own venues
don't owe you the time of day when it comes to "free speech".

--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

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



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
2018-05-24 18:19 GMT+02:00 <[email protected]>:
> Can you identify which of my posts violated the Code of Conduct for the
> internals list? Can you even find a Code of Conduct? Being banned because I
> consistently violated the code is one thing, but being banned just because
> someone did not like what I had to say is something else entirely.
>
> If you want to read the history of events then take a look at http://www dot
> tonymarston dot net/php-mysql/on-being-banned.html

If you want to get unbanned then try to reach out to the proper
sources (the general list is not one of them). Continuning this way is
most likely not gaining anyones favor and to me personally, changing
the original topic, is just useless noise. As much as I would answer
your post, I don't want to do it for the sake of contributing more to
the off-topic so lets leave it like that.


--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
"Paul M Foster" wrote in message
news:[email protected]
>
>On Thu, May 24, 2018 at 03:01:18PM +0100, tony@marston-home.demon.co.uk
>wrote:
>
>[snip]
>
>> That just proves that the age old notion of free speech does not exist on
>> the internals list.
>
>I'm not involved in any of the current drama and I have no skin in this
>game. But I do get tired of people who are called out for bad behavior
>consistently claiming that some supposed right to free speech they think
>they have has been trampled. Indeed, you do have an a priori right to
>speak freely. But that "right" may be curtailed relative to the venue
>involved. Realize that in order to speak as freely as you like, you may
>have to devise your own platform from which to speak. Because people in
>their own venues don't owe you the time of day when it comes to "free
>speech".
>

Ignoring the reasons for me being banned, what do you think of the idea that
a BC break can be snuck into the language WITHOUT prior warning, WITHOUT
being discussed in the internals list and WITHOUT being voted upon, and
WITHOUT any changes in the documentation? *THAT* is the real issue here.

If this is allowed to become standard practice then I'm afraid that the PHP
language will become so unreliable that it will be effectively unusable.

--
Tony Marston


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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
"Paul M Foster" wrote in message
news:[email protected]
>
>On Thu, May 24, 2018 at 03:01:18PM +0100, tony@marston-home.demon.co.uk
>wrote:
>
>[snip]
>
>> That just proves that the age old notion of free speech does not exist on
>> the internals list.
>
>I'm not involved in any of the current drama and I have no skin in this
>game. But I do get tired of people who are called out for bad behavior
>consistently claiming that some supposed right to free speech they think
>they have has been trampled. Indeed, you do have an a priori right to
>speak freely. But that "right" may be curtailed relative to the venue
>involved. Realize that in order to speak as freely as you like, you may
>have to devise your own platform from which to speak. Because people in
>their own venues don't owe you the time of day when it comes to "free
>speech".
>

There is a big difference between saying something that breaks the code of
conduct and saying something that someone dislikes. Can you point to any of
my posts and say "this post breaks that code"? Can you even point to a Code
of Conduct?

FYI I was never contacted by a moderator and warned that if I did not
self-moderate my posts that I would be suspended or banned, I was just
banned. This I think is a violation of procedure.

--
Tony Marston


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
That first link of yours merely asked us both to calm down, which I did. It certainly was not a warning from a moderator that if I persisted that I would be banned.



That second link of yours contains this quote from Stanislav Malyshev: “you don't have the rights to be in the list if the community does not want it”. This means that even if you do not break any published rules that you can be banned just because someone does not like what you have to say. So if someone proposes a BC break and I argue against it he can complain and have me banned. Does this sound fair to you?



Your third link indicates that you do not understand how session_name() is supposed to work. It can either be used to get the current session name, set a new one, or both at the same time. This makes it perfectly clear that it is valid to run session_name() while a session is active. The only point to recognise is that if you set the session name this will not take effect until the next session_start(), and it is ONLY session_start() which will fail is a session is active.



When programmers use session_name() they use it in either the get or set modes and rarely for both at the same time. That is why few people spotted the bug that when you try to do both it actually does neither. This is the only bug is session_name(), and this was never fixed.



In 7.2 the behaviour was changed so that session_name(‘newname’) will now fail if a session is active. So instead of fixing a genuine bug a new artificial bug was introduced. I say “artificial” simply because it was changed because someone thought that it was not logical to set a session name while another session was already active. The manual clearly states that it should be possible to run session_name() while a session is active. It is only session_start() that will fail if a session has already been started.. Thus the following sequence was perfectly valid until 7.2:

session_start();

session_name(‘newname’);

session_write_close();

session_start();



I repeat, the change in 7.2 did not fix the real bug but introduced a new and artificial bug.



Tony Marston



________________________________
From: Christoph M. Becker <[email protected]>
Sent: Thursday, May 24, 2018 2:02:38 PM
To: Tony Marston; php-general@lists.php.net
Subject: Re: [PHP] BC break in 7.2 caused by undocumented and unauthorised change

On 23.05.2018 at 17:29, Tony Marston wrote:

> If you read that post you will see that it was mostly complaining about
> the person known as "rhsoft". All I did was argue AGAINST his viewpoint,
> yet I was still banned in what I would call an arbitrary manner. Note
> that I say "banned" and not "suspended" as I was not informed of what
> action was to be taken against me, nor was I given a chance to explain
> myself.

FTR: you have been repeately admonished for offending the mailing list
rules and netiquette by several people, for instance in
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnews.php.net%2Fphp.internals%2F100765&data=02%7C01%7C%7Cfe08c799e18549a00d6b08d5c176a211%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636627637619303667&sdata=RLSQJDIk7x94Tt7HCLv34xn0fsxD49T2yFk6lEYPwXU%3D&reserved=0. Even after it has suggested
to suspend your mailing list access, you have not shown insight or
regret, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexternals.io%2Fmessage%2F101479%23101501&data=02%7C01%7C%7Cfe08c799e18549a00d6b08d5c176a211%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636627637619303667&sdata=0S%2BBiLk%2BD2TCXx19opRNizyzBoy40MN%2BEp%2BV0ASDK3k%3D&reserved=0, for instance.

Wrt. the actual issue see my comment in https://nam04.safelinks.protection..outlook.com/?url=https%3A%2F%2Fbugs.php.net%2F76358&data=02%7C01%7C%7Cfe08c799e18549a00d6b08d5c176a211%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636627637619303667&sdata=WgFXFURmwH5NmRwyC0sP1I3ehXRMHxmQf4pIKT6wqww%3D&reserved=0.

--
Christoph M. Becker
Sorry, only registered users may post in this forum.

Click here to login