Edit report at https://bugs.php.net/bug.php?id=38104&edit=1
ID: 38104
Updated by: yohgaki@php.net
Reported by: m dot v dot veluw dot smscity at gmail dot com
Summary: session_start()/session_write_close() creates
multiple session cookies headers
-Status: Not a bug
+Status: Re-Opened
Type: Bug
Package: Session related
Operating System: any
PHP Version: 5.1.4
-Assigned To:
+Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2014-09-10 05:59:42] bgardner at noggin dot com dot au
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
------------------------------------------------------------------------
[2013-05-29 02:47:34] jonathan at doubledotmedia dot com
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
------------------------------------------------------------------------
[2012-11-17 02:22:55] denis_truffaut at hotmail dot com
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).
------------------------------------------------------------------------
[2012-09-26 00:13:58] chris at ctgameinfo dot com
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."
------------------------------------------------------------------------
[2012-05-08 17:02:13] andries dot malan at gmail dot com
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
------------------------------------------------------------------------
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=38104
--
Edit this bug report at https://bugs.php.net/bug.php?id=38104&edit=1