php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31455 multiple session_start() creates multiple session cookies in HTTP-Response
Submitted: 2005-01-09 15:49 UTC Modified: 2005-02-14 00:18 UTC
Votes:33
Avg. Score:4.1 ± 1.1
Reproduced:24 of 25 (96.0%)
Same Version:11 (45.8%)
Same OS:7 (29.2%)
From: rene dot bangemann at web dot de Assigned: tony2001
Status: Wont fix Package: Session related
PHP Version: 4CVS, 5CVS OS: Win32
Private report: No CVE-ID:
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rene dot bangemann at web dot de
New email:
PHP Version: OS:

 

 [2005-01-09 15:49 UTC] rene dot bangemann at web dot de
Description:
------------
I'm using a combination of session_start() and session_write_close() to access and update session variables.
In some scripts this function calls will be executed up to 50 times.
For each call of session_start() a HTTP-Header with the PHP session id will be created in the same HTTP response.
I would expect, that in the HTTP response will be only one HTTP-Header with the session id.

Reproduce code:
---------------
<?php
session_start();
session_write_close();
session_start();
session_write_close();
session_start();
session_write_close();
?>

Expected result:
----------------
HTTP-Header Set-Cookie with PHP session id created only once in HTTP response

Actual result:
--------------
The code above will create a HTTP response with three identical HTTP Set-Cookie headers

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-13 09:44 UTC] sniper@php.net
Then how would you handle this (very unlikely :) code:

<?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2'); 
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3'); 
session_id('foobar3');
session_start();
session_write_close();
?>

Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions   in single request, why should we not allow it?

(this is actually for Tony, FYI when he figures out how to fix this bug :)

 [2005-02-13 18:03 UTC] tony2001@php.net
Okay, no more dirty hacks =)
Marking it as "won't fix" and considering as a feature.
 [2005-02-14 00:18 UTC] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one request. But thats not my use case:

I'm using a PHP script to perform some actions which can take up to some hours.
E.G. for displaying progress information about the running process a second php script needs to access the session vars. This forces to close the session file via session_write_close() in the first script. After this function call, the second PHP script can do a session_start() and access the current values of the session vars.
After finishing the second request the session file will be closed again.
If the first script has to store new values of session related vars in the session file, it uses a combination of session_start() and session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long execution time).

Under normal circumstances I could live with this feature :-). But I'm afraid that in combination with HTML frames this behaviour of PHP can force deadlocks in different browsers like Internet Explorer or Mozilla. Unfortunately I can't present a 100% working example for reproducable deadlocks.

I would suggest to create a flag containing true or false, if the Cookie for the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of course another Cookie has to be sent.
 [2010-10-15 23:26 UTC] WarrenGaebel at FriendlyNeighbourGuide dot ca
I am experiencing a similar, but not identical problem.

I reload my page multiple times, using session_start() every time it loads.  JavaScript sets cookies that I use in php.  When using Internet Explorer, $_ENV["HTTP_COOKIE"] contains multiple entries for each cookie.  This does not happen with Firefox.

As near as I can figure so far, when executing code at a domain named x.y.z, Internet Explorer sends the cookies for x.y.z followed by the cookies for y.z.  Php then puts both sets of cookies into $_ENV["HTTP_COOKIE"].

Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an Internet Explorer bug.  I post it here in the hope that it may help you resolve your problem.

          ... Warren Gaebel, B.A., B.C.S.
 [2011-11-20 05:21 UTC] danielc at analysisandsolutions dot com
See also: https://bugs.php.net/bug.php?id=31455
 [2011-11-20 05:22 UTC] danielc at analysisandsolutions dot com
I mean to say, see also: https://bugs.php.net/bug.php?id=38104
 [2015-08-10 20:07 UTC] waldoc at latinmail dot com
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
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC