The documentation also clearly states "Thus, you need to call session_name() for every request (and before session_start() or session_register() are called)."

http://php.net/manual/en/function.session-name.php

I already use session_name() to provide the name of the new session before I start that session with session_start(). The problem is that the function no longer works as AS ADVERTISED as it can no longer return the name of the existing session before it starts the new one.

This function has worked AS ADVERISED for over 15 years, so why was it changed? For what problem is this change in behaviour supposed to be a solution?

The description of the function's return value says
"If name is given *AND* function updates the session name, name of the old session is returned. [emphasis mine]"

Like many other functions, if session_name() fails (such as when attempting to change the session name of a session has already been started), it now returns false; previously it would just fail silently and return the old name without comment.

There is nothing in the documentation which says that you cannot use session_name() to change the name of a session that has already started. This is a legitimate thing to do if you want to access the same session data with a new name and id. Take the following code:

$name1 = session_name();  // returns 'PHPSESSID'
$id1   = session_id();    // returns empty string
session_start();
$name2 = session_name();  // returns 'PHPSESSID'
$id2   = session_id();    // returns non-empty string
session_name('NEWSESSID');
$name3 = session_name();  // returns 'PHPSESSID' instead of 'NEWSESSID'
session_regenerate_id();
-- restart script to use new session

Note that as of 7.2 $name3 now contains the OLD name instead of the NEW name. 

If the problem was that it changed the session name but failed to return the existing name then the CORRECT fix would be to make it return the existing name AS WELL AS changing to the new name.

Where was this "problem" ever reported as a bug?

When was this change in behaviour ever discussed and voted upon by the internals group?

This is a BC break which has not been documented anywhere, nor was it ever discussed on the internals group.

> If the problem was that it changed the session name but failed to return the existing name then the CORRECT fix would
> be to make it return the existing name AS WELL AS changing to the new name.
The problem, as I understand it, was that it seemed like changing the session name while the session was in progress appeared to be allowed - meaning the function would not error. The fact that changing the name didn't affect the current session was secondary, even if it was more apparent.

It's clear to me from the current and past implementations that session_name() was never meant to alter the current session's name. The documentation does not clarify whether the behavior it states applies if the session has or has not been started and without that I find what it says to be ambiguous.

> Where was this "problem" ever reported as a bug?
Not all changes to PHP require a dedicated bug report. This one came during other session fixes for bug #71038.

> When was this change in behaviour ever discussed and voted upon by the internals group?
Not all changes to PHP require an RFC. This one was mentioned on the internals list by @yohgaki in mid October 2016 ("Fixing insane session_start() behaviors") and the discussion lasted for a couple days without any dissenting opinions offered.

> This is a BC break which has not been documented anywhere,
It was listed in UPGRADING
  https://github.com/php/php-src/blob/PHP-7.2.0/UPGRADING
however I see that it was not then added to the online migration guide.

The change is deliberate but the documentation is insufficient and must be updated.


If you want multiple sessions then you need to what should hopefully make sense: session_write_close() the old one (or have opened it with read_and_close=true), change the name, and session_start() to get the new one.

The fact that session_name() was mentioned in that list of changes in that GitHub page is irrelevant. The precise change, and that it broke BC, was not specified. It was NOT mentioned in any official documentation on the PHP website, and it was NOT mentioned in any change logs.

Bug #71038 did not mention any problem with session_name, nor did it indicate that it would be changed.

The fact that you think that it is not correct to create a new session name while a current session is active is irrelevant. That is what the function allowed for more than 15 years, and that is what the documentation said it would do. Nowhere does it say that you cannot change the session name if a session is already active.

I repeat, this is an undocumented BC break that was never discussed on the php.internals group and was never voted upon, therefore I regard it as an unauthorised change.

I do not see why us developers in userland should have to change our code to deal with your mistake. The old behaviour did NOT cause any problems, so I demand that you revert this change immediately.

I'm sorry but since this behavior now exists in PHP 7.2, fixing it would be a BC break and we wouldn't want to make developers in userland have to change their code to deal with our mistake. This should be discussed in the PHP internals group and voted upon.

That is what you wanted, right? Due process? Or shall we ignore it this time too?

How can reverting code which caused a BC break be a BC in itself? What existing scripts which may have been modified to get around the BC break which you introduced would be broken if the original AND DOCUMENTED behaviour were to be reinstated? If the userland fix to get around this BC break is to insert a call to session_write_close() before the call to session_name() then what harm would it cause? It would just mean that the call to session_write_close() would be redundant. It would certainly not cause an error.

>Not all changes to PHP require an RFC. This one was mentioned on the internals list by @yohgaki in mid October 2016 ("Fixing insane session_start() behaviors") and the discussion lasted for a couple days without any dissenting opinions offered.

During the discussion on the internals list and on github, @yohgaki did mention that he _should_ have written an RFC on the subject, but never got around to doing so. Perhaps he could write one ex post facto to consolidate the whys and wherefores of this change and serve as a future citation reference.

I have checked that discussion, and NOWHERE does it mention a change in behaviour for session_name() that would cause a BC break. This was never identified, discussed, or voted upon, therefore I consider it to be an unauthorised change.

Changing the behaviour back to what it originally was, and AS DOCUMENTED for the past 20 years, will not cause any BC breaks, so your "fix" for a problem which did not exist in the first place should be reverted.

I am HORRIFIED to find that a change was made that was not personally signed off by Toby.

I will not be using PHP any more, this is the final straw. I can cope with the weird names and inconsistent APIs and segfaults and projects possessed by demonic forces, but I WILL NOT support a community that does not respect such wise people as Tiny.

> I expect session_name() to do what it has been doing for the
> past 15 years, that is to return the existing session name while
> assigning a new one.

It did not change the session name, though.

> The documentation clearly states "Get and/or set the current
> session name", and the "and/or" indicates that it should be able
> to do both at the same time.

The documentation also clearly states:

| Thus, you need to call session_name() for every request (and
| before session_start() or session_register() are called).

And:

| If name is given and function updates the session name, name of
| the old session is returned.

Since session_name('foo') does not update the name of the session
if it has already been started, it *must* not return the name of
the old session according to the documentation.

> It did not change the session name, though.

Yes it did. I stated using "session_name('newname')" as early as 2003 (and documented on my website in 2005). It kept on doing just that until it was broken in 7.2.

> The documentation also clearly states:

| Thus, you need to call session_name() for every request (and
| before session_start() or session_register() are called).

That means that you must follow a call to session_name() with a call to session_start() before the new name can take effect. It *DOES NOT* mean that you cannot call session_name('newname') while the current session is still active.

> Since session_name('foo') does not update the name of the session
> if it has already been started, it *must* not return the name of
> the old session according to the documentation.

The fact that "$oldname = session_name('newname')" did not work AS DOCUMENTED was a bug. The description for this function CLEARLY states the following: 
"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.

That clearly states that you should be able to both return the name of the current session *AND* set a new session name at the same time. It was *NEVER* necessary to close the current session before changing its name.

This discussion hurts my brain; can it start over and be simplified? Example:

session_start();
$old = session_name('foo');

Do I understand the change here? In that:

 * Before 7.2: $old = the current session name
 * 7.2: $old = false; and E_WARNING generated
 
 * Before 7.2: session name does not change to 'foo' as it's after session_start()
 * 7.2: same, session name does not change to 'foo'

Also, curious, is the following also affected in PHP 7.2? I assume not:

session_start();
$old = session_name(); // current session name

If I understand it correctly then there was a BC break. The change probably saw it was silly to allow session_name('foo') in situations that the session name could not change, which I understand, now should the return value have also changed without official deprecation first? Probably. Returning false now means that the session name could not be changed when before it simply returned the current session name.

FWIW, and if I understand the change here, I'd leave the change at this point although it's not an easy decision. Using session_name('foo') means the programmer expects 'foo' as the new session name as otherwise the bogus code should fail. I can't think of another use case or reason it should not fail but maybe others can.

> Do I understand the change here?
Yes. Before it returned the name (and didn't change), now it returns false.

> Also, curious, is the following also affected in PHP 7.2? I assume not:
Correct. The warning and false only apply when a name argument is passed.

So that's FOUR different opinions on the behavior of session_start() + session_name($new):
1. It should change the active session name and return the old one; the fact that 7.2 warns and returns false is thus moot. PHP has never done this but the rationale is that it should because the docs supposedly say it should. Unknown what would happen if headers had been sent, or how it would manage both the old and new session data. BC with 7.2 but not <7.2.
2. It should change the session name (literally the session.name setting), which would affect the next session and not the current one, and return the old name. This is <7.2's behavior.
3. It should not change the session name but it should return the "old" (still current) one. As such it should warn that the name couldn't be changed. This is a compromise between 2 and 4. Is BC.
4. It should fail (ie, warn and return false) because the session name cannot be changed. Rationale is that changing the name was presumably the intention behind calling the function with a name argument, and therefore that the <7.2 behavior was a bug which 7.2 has fixed. Not BC with <7.2 but does expose underlying bugs regarding multiple sessions.

Note that the only real difference between 1 and 4 is whether it's possible to "rename" an active session.

Actually, correction on 3:
> 3. It should not change the session name but it should return the "old" (still current) one. As such it should warn
> that the name couldn't be changed. This is a compromise between 2 and 4. Somewhat BC.
"Somewhat" because it depends on the code, like whether it calls any additional session functions.

But forget that. I just realized that the use of session_regenerate_id is significant because it closes and reopens the session - it doesn't just change the ID but works like a session_write_close() + session_start(). The question as to what session_start+session_name should do is still relevant, but @tony's original code subtly (and perhaps accidentally) did make use of the renamed session.

So there's that to consider. It hasn't changed my opinion though.

Just in case, I did not suggest opinion #3 to do today but rather think it was "probably" a good option to consider for 7.2.0. But I didn't realize #2 was pre-7.2 behavior and thought all it did was return the current session name. Anyhow, this old-timer will stop cluttering this bug with uneducated words now :)

There are two uses for session_name:
1) Return the current session name.
2) Assign a new session name.

According to the documentation for the last 20 years it should also be possible to do both, which implies that it is not necessary to close the current session before using session_name('newname'). The fact that it does not do that is a bug. Few people spotted it is simply because they generally want to do one or the other, but rarely both at the same time.

The reason that I want to change the session name is that when I have a particular part of my enterprise application open in one browser window I sometimes want to open a second browser window (or even a third) so that I can look at another part of my application at the same time. In Internet Explorer the Ctrl+K key combination will produce a clone of the current tab in another tab. However, at this point they are both using the same session name and id, so I have a hyperlink on the screen which executes the following code:

session_start();  // this uses the old name and id
... do stuff
session_name('newname');
session_regenerate_id();
session_write_close();
… restart script so that it uses the new session name and old,
… but leaves the old one alone.

Since PHP 4 all the way up to 7.1 this worked as advertised. Since 7.2 the call to session_name('newname') does NOT change the session name because somebody decided that it was not proper to do so while a session was already active. That opinion differed from the documentation, therefore that opinion was wrong.

The fact that I can workaround this newly generated BC break by moving a single line of code is not the issue. The important fact is that this BC break happened WITHOUT WARNING and without ever being documented or appearing in any change logs.

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. If any Tom, Dick or Harry can now insert a BC break at any time without warning, then that sounds the death knell for the language. It will become so unreliable it will become unusable for anyone who expects to build an application with a long life.

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.

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".

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().

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.

> 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>

> 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".

These are the five code samples that Yasuo sent me as "proof" of the broken behaviour with the session functions which his fix supposedly cures. Below each example is my response which shows that the problem actually lies with the code that calls those functions and not the functions themselves.

Example #1 - Wrong write and/or crash>
<?php
session_start();
session_name('new_name');
session_commit(); // Save handler can write session data to wrong storage.

There is no such thing as "wrong" storage in this case as session_commit() does NOT reference $session_name when calling the write() method in the session handler, it uses $session_id. This code does not change $session_id so the session data is put back in the same place from where it was read.

Example #2 - Wrong name returned
<?php
session_start();
session_name('new_name');
// somewhere in the code
$my_current_session_name = session_name();  // Wrong session name. session_start() uses old one.
// This behavior can cause bug when user is distributing session storage accesses by session name.

There are a number of glaring mistakes here:

- Changing the value of session.name does not take effect until the next call to session_start(). When a session is started the value of session.name is provided in the $session_name argument in the open() method in the session handler.
- No method or function has ever been provided which will return the value of $session_name which was used in the call to open().
- If the value of session.name is changed while a session is active that change is not communicated with the session handler and does not affect the session handler in any way as all read() and write() operations are performed using the $session_id.
- If the session name is used to change the value in $save_path then it should be done in the open() method in the session handler where both $save_path and $session_name are provided as arguments. If these values need to be used in other methods then they should be stored as class properties and accessed using $this->varname.

Example #3 - Wrong write and/or crash. Pattern 2.
<?php
session_start();
session_name('new_name');
// somewhere in the code
session_regenerate_id();  
// Save handler can write session data to wrong storage.
// In worst cases, PHP crashes
?>

Bad usage again. session_regenerate_id() will regenerate a new id for the CURRENT session, but this will be linked with the value of session.name which was available when the current session was started. The value 'new_name' will not take effect until the next call to session_start(), just as the manual says.

Example #4 - Wrong write and/or crash. Pattern 3.
<?php
session_start();
session_name('new_name');
session_write(); // Save handler can write session data to wrong storage. 
// In worst cases, PHP crashes
?>

This is the same as Example #1.

Example #5 - Wrong write and/or crash. Pattern 4. + Bogus session_name() call.
<?php
session_start();
session_name('new_name');
// Save handler can write session data to wrong storage at the end of script execution.
// In worst cases, PHP crashes
// In addition, user wouldn't notice bogus session_name() call if there is no error.
?>

This is a duplicate of #1 and #4. The session is started with a particular $session_id, and as that $session_id is never changed any updates to that session data will be written back using the same $session_id. A change in $session_name does not change the $session_id. The $session_name and $session_id are different entities which are accessed using different functions. They are only brought together when the cookie is accessed, which is either by session_start() or session_regenerate_id(). This code does nothing to cause 'new_name' to be written out as a cookie, therefore it simply disappears.

+1, very problematic when we must migrate from 7.1 to 7.3

I guess reverting to the old behavior is the way to go, but
apparently that would require an RFC now, so likely it won't
happen.  SCNR.

Session name MUST be specified before starting session. Otherwise it will NOT take effect since output is already started. (i.e. HTTP header is already sent)

With output buffering, output may delay and it is possible change buffered HTTP header and outputs (Note: transid requires to rewrite buffered output. This isn't simple) 

In addition we have user defined and 3rd party session save handlers which can use session name for some reasons to achieve better session management.

Simply restoring old behavior allows hard to find find bug in PHP session because it cannot working correctly.

Older PHP session was allowing too many bogus operations which will not work at all, and works only for specific condition. This is one of them.