Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Session is created every time you call session_start(). If you 
want to avoid multiple cookie, write better code. Multiple 
session_start() especially for the same names in the same 
script seems like a really bad idea.

I can not tell how much I disagree on this. Calling session_start() followed by session_write_close() is a very valid way to avoid blocking multiple processes. (See also here http://konrness.com/php5/how-to-prevent-blocking-php-requests/.) This problem is huge since we are facing fatal crashing clients due to zillions of duplicate PHPSESSID entries in one cookie. Our server is big and complicated and so we are not willing to change anything in this area while all is already taken in production. Totally stuck on this and I'm not happy. This is a very obvious PHP bug that can be proven in 4 lines of code without any client intervention.

I just ran into this bug in PHP 5.3.5 when working with a script that does lots  
of 
session_start()/session_write_close() in a long-running task, so that separate 
requests can still access the 
session during that long task. (Specifically those separate requests are 
checking the progress of the long 
task.)

The resulting absurdly redundant Set-Cookie header caused Firefox 7 to lock up 
for a few seconds, and caused IE8 
to give its infamously useless "Internet Explorer cannot display the webpage" 
page. So this bug is not "Bogus" s 
it claims.

I do have a workaround, however. I'm already doing an ob_start() at the top of 
the script, and now before the 
ending ob_end_flush() I replace the Set-Cookie header with a new one:

  if (SID) header('Set-Cookie: '.SID.'; path=/', true);

After adding this, I no longer have the above problems in Firefox and IE.

See also https://bugs.php.net/bug.php?id=31455

I believe the problem is a missing PHP capability for session handling,without 
which no efficient solution is possible for this problem.

In addition to session_start() and session_write_close(), PHP should have a 
session_write_reopen() function.

This would solve several problems cleanly.

It will allow for those that want fine-grained control over the transaction 
handling/demarcation when accessing session variables, without imposing any 
additional complications on those that just want the default session handling 
behavior.

for example:

at the top of all pages you start your session with:
session_start(); session_write_close(); //no further blocking

//.. rest of long running script execution

//now we only block for tiny fraction of time while manipulating session vars
startSessionTransaction();
$x = $_SESSION['x'];
$x++;
$_SESSION['x] = $x;
endSessionTransaction();
//now we stop block

//... script can continue running tedious operations without blocking others on 
session access 
//...


and the user would then implement these

function startSessionTransaction()
{
  session_write_reopen();
}

function endSessionTransaction()
{
  session_write_close();
}


Now you can only let your session handling part of your script block for the 
tiny parts when a session variable is manipulated, without 
having to completely restart sessions, because restarting sessions later in your 
script creates several additional problems as noted - such as creating duplicate 
session cookies, and just as annoying, force you to turn on output buffering for 
your entire script, since you cannot start (or restart) session's once any 
output has been sent to the browser.

This is the solution required. This is what is missing in PHP session 
functionality. IMNSHO

According to rfc6265 it definitely is a bug

"Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name."

I agree with all previous comments.

Multiple AJAX long running processes, like AJAXed HTML 5 photo multi uploading 
(to be very concrete) require intensive session_write_close, and may need to 
restart session.

So if i had to upload 150 photos in the same time, i will perform 150 
session_start / session_write_close / long running process / session_start / 
session_write_close /... etc

This behavior should not lead to crash the browser.

session_start is expected to reopen the session, or please provide a function to 
reopen the session in write mode (with all locks and wait times it involves).

I am encountering the same issue at the moment on a codebase I am working on; the 
issue we are seeing is that we make many simultaneous AJAX requests, but they 
block each other because only one can hold the session open at a time.

We are currently working around it by using multiple session_start() and 
session_write_close() functions, but this is sending multiple (identical) Set-
Cookie headers to the client, which is incorrect.

Either session_start needs to not send duplicate headers, or we need a 
session_reopen() function

The following highlights the bug

<?php

session_start();
$old_id = session_id();
session_regenerate_id();
$new_id = session_id();
session_write_close();

?>
<html>
<head>
<title>Session test</title>
</head>
<body>
<p>Old id : <?php print $old_id ?>
<p>New id : <?php print $new_id ?>
</body>
</html>

If you hit this page on a domain you have not previously visited, it will send two Set-Cookie headers for the session id

This is a common scenario when logging in to prevent session fixation attacks

https://www.owasp.org/index.php/Session_fixation

This is not a problem if the user does

1. Login screen - display form controls to login
2. Submit credentials to login page - session regenerated

However, if they directly submit their credentials without first visiting the domain, then it does occur

I don't remember well, but I think I've dealt "multiple cookies" issue partially. I might not for this case. I'll fix it sends multiple cookies, please let us know.

Unfortunately, PHP does not make sure that old session is not deleted. If old session was authenticated before session regeneration, bad luck. (We could still say "it's users fault", though)

To remove old session, it must be deleted asynchronous manner. However, few people against this change and insist synchronous deletion which cannot be done. (i.e. Web server and client is _not_ synchronized, thus synchronous deletion can cause serious problem)

Anyway, please update PHP version if there is issue. If not, please close this again. Thank you.

If only one header is sent, multiple sessions cannot be used. Therefore, it will not be fixed.

A LOT of people is using session_start(); and session_write_close(); as a way to update $_SESSION data and make it available for other scripts (usually called using AJAX)

The problem is session_start(); and his SEND HEADERS AGAIN Feature.

So the solution is simple:

Add a new function called session_write_open(); in order to be used with session_write_close();

Headers are only set by session_start(), and session_write_open() will resume  that session without sending headers again.

If that solution is too complicated, then add a new option to the session_start(); ie: session_start(MUTE_HEADERS) that restore the session without send headers again.

I'm pretty sure that the second implementation is even more easy and fast to implement, because if MUTE_HEADERS are set, then you got to skip the send header part of the function.

Hope this features will be present in the next release.

Best regards

Time goes by. 
I fixed this already. If you have problem, please open new bug report.

How this issue was fixed? I'm facing the same situation now.

I'm having this same issue... A session_write_reopen($session_id) function would easily solve this issue imho. I don't see how this is taking 10 years to solve.

A workaround to this issue would be passing the "session.use_cookies" as false in the $options argument the 2nd time you use session_start(). This off course would only work for users of PHP7.

I also just ran into this issue on PHP 5.6.30-7+deb.sury.org so if it was fixed it would be nice to know which version it was fixed in.

I have a long running download process kicked off from an Ajax request to PHP that updates state every few seconds to $_SESSION that calls session_start() before each update and session_write_close() after.  Subsequent Ajax calls to check state are sent every few seconds by the browser.

Longer requests would never seem to terminate and it was because hundreds or more Set-Cookie lines with the same session_id were being sent.  The browser or Ajax stack couldn't handle all the header data (but no PHP or browser script errors).

PHP source didn't yield any solutions but revealed a workaround.

In the long running script, add this before the later session_start() calls:

ini_set('session.use_cookies', 0);


At the very least PHP sees this setting when calling session_start() and will not append additional session ID cookies to the response.  This fixed the issue for me.