Edit report at https://bugs.php.net/bug.php?id=76358&edit=1
ID: 76358
User updated by: tony at marston-home dot demon dot co dot uk
Reported by: tony at marston-home dot demon dot co dot uk
Summary: Cannot change session name when session is active
Status: Assigned
Type: Bug
Package: Session related
Operating System: Windows 10
PHP Version: 7.2.5
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
> Not every (minor) BC breaking change requires an RFC or discussion
on the internals mailing list.
There is no such thing as a "minor" BC break. Every BC break causes code that previously
worked to suddenly fail for no good reason.
Every BC break should be discussed on the internals list so that other developers can review it to
see if it is actually justified or can be improved. It must then be voted upon, which then means
that the change MUST be subject to an RFC.
The idea that a developer can sneak in a BC break WITHOUT it being discussed on the internals list
and WITHOUT any prior warning or even a mention in the change log will create a bad smell for the
millions of application developers who expect the language to be reliable and stable. It is the fear
of BC breaks which causes developers to delay upgrading to the latest version of the language.
> This very change was submitted as pull request on Github (which is an official and publicly
> available channel)
GitHub may be the official channel for pull requests, but it is *NOT* the official channel for
discussions. There were *NO* discussions on the proposed changes to session handling which
identified this change to session_name().
> I still do not think that your interpretation of the (former) documentation is
absolutely correct; at the very least there is some room for interpretation.
The documentation at http://php.net/manual/en/function.session-name.php
is perfectly clear - the session_name() function can be used either to get the current name or set a
new one, or even both at the same time. Example #1 in the manual clearly demonstrates this usage.
This means that it has always been perfectly legitimate to call session_name() even if a session is
already active.
The documentation also states: "The session name is reset to the default value stored in
session.name at request startup time. Thus, you need to call session_name() for every request (and
before session_start() is called)."
This tells me that if you change the session name that it will not be effective until the next call
to session_start().
> Yasuo claims ⦠"the former behavior is not valid and allows crash and
> misbehaviorsâ
I have been conversing with Yasuo via private email on this claim, and he sent me five examples of
code where there was a call to session_name('newname') after a call to session_start() and
it did not work as expected. This is simply because there was *NO* call to session_start() after a
change in name EVEN THOUGH THE DOCUMENTATION SAYS THAT THERE SHOULD BE, or that the 2nd call to
session_start() failed because a session was already active. The documentation at http://php.net/manual/en/function.session-start.php
clearly states: "As of PHP 4.3.3, calling session_start() after the session was previously
started will result in an error".
It is obvious to me that if session_name('newname') is called when a session is already
active then the new name will not take effect until the next call to session_start() and that the
2nd call to session_start() must be preceded by a call to session_wtite_close(). It was a mistake on
Yasuo's part to think that it was the call to session_name() which should be preceded by
session_write_close().
This mistake was brought about by his misunderstanding of how the various session functions could
legitimately be used. He actually admitted to me in one of his emails: "I didn't expect
users to call session_name() after session_start() because it does not make sense with session
module structure".
There you have it. It didn't make sense to him, so he changed the behaviour of the function to
forbid it. Even worse, he changed the legitimate behaviour of this function without any discussion
or warning whatsoever, and without even a mention in the change log. This is a very bad precedent
which, if allowed to continue in the future, will cause millions of application developers to lose
confidence in the language. We (because I am one of those application developers) expect the
language to be reliable and stable, and by "stable" I do *NOT* mean "full of
manure".
Previous Comments:
------------------------------------------------------------------------
[2018-05-30 21:30:15] cmb@php.net
> I think that it is a sad day when somebody can decide that the
> documented behaviour of a 20 year old function does not fit it
> with their beliefs, so they go ahead and change it without
> following the correct procedure - raise RFC, discuss it on the
> internals list, then put it to a vote.
Not every (minor) BC breaking change requires an RFC or discussion
on the internals mailing list. This very change was submitted as
pull request on Github (which is an official and publicly
available channel), and since there have been no general
objections, the PR was committed. Also note, that I still do not
think that your interpretation of the (former) documentation is
absolutely correct; at the very least there is some room for
interpretation.
Anyhow, assigning to Yasuo, who recently committed a documentation
change[1] which claims that the former behavior âis not valid and
allows crash and misbehaviorsâ. Maybe some short explanation what
could go wrong would be approriate here.
[1] <http://svn.php.net/viewvc?view=revision&revision=345080>
------------------------------------------------------------------------
[2018-05-30 13:59:20] tony at marston-home dot demon dot co dot uk
When the documentation at http://uk1.php.net/manual/en/function.session-name.php
says "session_name() must be called before session_start() in order session to work
properly" it actually means that the new session name will not take effect until the next call
to session_start(). It will not change the name of any currently open session.
------------------------------------------------------------------------
[2018-05-29 10:34:32] tony at marston-home dot demon dot co dot uk
When the documentation says that session_name() should be called before session_start() it means
that the name change will not take effect until the next call to session_start(). The reason that I
call session_start() before the call to session_name() is that I want to access the $_SESSION array
for the current session so that I can copy it across to the new session. I actually want to have two
browser windows running different parts of my application at the same time, and this will only work
if each of the browser windows has its own session_id, and this requires each session to have its
own name.
I have been using these functions as documented since 2003 without any problems, so imagine my
horror when this well-established behaviour was suddenly changed WITHOUT ANY WARNING WHATSOEVER.
Breaks in BC should always be handled by following the correct procedures, and I'm afraid that
those procedures were completely ignored on this occasion.
It is perfectly valid to call session_name() while a session is active as it would otherwise be
unable to follow the documentation and return the name of the current session. The documentation
also states that this function can be used to both get *AND* set the session name at the same time,
which means that it has always been possible to change the session name while a session is active.
The new name will not take effect until the next call to session_start(), and it is *ONLY*
session_start() that will fail if a session is already active. Thus it is *ONLY* necessary to close
the current session before the 2nd call to session_start(), *NOT* the call to session_name().
The only bug with session_name() is that if you tried to both get *AND* set at the same time it
would actually do neither. In changing the documented behaviour of this function they failed to fix
a genuine bug and instead introduced an artificial one.
Note that session_name does NOT change any session cookies. That is done either by
session_regenerate_id() or session_start().
------------------------------------------------------------------------
[2018-05-29 09:53:41] a at b dot c dot de
I have to admit; the semantics of the session_* functions are a bit murky to me. The only time
I've found a use for session_name was to avoid a collision with a third-party package's
use of PHPSESSID. I've never tried changing the name of an active session until this.
Thing is, the documentation has always said that session_name() should be used BEFORE
session_start(). Right in the function's description. "The session name is reset to the
default value stored in session.name at request startup time. Thus, you need to call session_name()
for every request (and before session_start() or session_register() are called). "
The currently top-voted user comment, made by Hongliang Qiang fourteen years ago recognises that
"...the session already started thus cannot be altered before the session_name()
function--wherever it is in the script--is executed, same reason session_name needs to be called
before session_start() as documented.".
As far as I can see, trying to change the session name of an active session would - if it worked at
all - would just cause _two_ Set-Cookie headers (one sent when the session started and one when the
name changed) with the _same_ session ID value (hence both referring to the same session). The
client would send both cookies back. I suppose regenerating the ID sends a _third_ Set-Cookie
header, with a repeated name and the new value, but because the name's repeated there's
explicitly no guarantee which (if either) value would be retained by the client.
But, like I said, I find the semantics of the documented functions a bit cloudy. In the synopsis,
for example, the phrase "current session name" could be parsed as "current-session
name" or "current session-name". Documentation and behaviour suggests it should be
the latter, because when it's called there shouldn't be a "current-session".
------------------------------------------------------------------------
[2018-05-25 23:14:37] tony at marston-home dot demon dot co dot uk
The function was changed to ignore the documented behaviour when it should have been changed to
IMPLEMENT the documented behaviour. There is no logical reason to prevent the session name being
changed while a current session is active. The fact that the new name cannot be used until the next
call to session_start() is neither here nor there.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=76358
--
Edit this bug report at https://bugs.php.net/bug.php?id=76358&edit=1