Edit report at https://bugs.php.net/bug.php?id=31455&edit=1
ID: 31455
Comment by: martin at parentnode dot dk
Reported by: rene dot bangemann at web dot de
Summary: multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package: Session related
Operating System: Win32
PHP Version: 4CVS, 5CVS
Assigned To: tony2001
Block user comment: N
Private report: N
New Comment:
I also experience a very real problem based on this "feature" â the header length,
given a high number of identical Set Cookie headers caused by session_start() will crash most modern
browsers. I understand the feature of this when it comes to multiple different cookies â but
with multiple identical cookies it is harder to understand this as any kind of feature.
I think both issue and a good solution proposal have already been provided by other developers. AND
I find it a bit arrogant that this problem has been shot to the dark "Wont fix" corner
â as a feature. The proposal by waldoc allow you to keep your feature â and remove the bug
part. The arrogance is in thinking that using session_start multiple times in a script is a bad
idea. There are very real scenarios where that is a very good option â unless you want the
end-user to suffer death by waiting time and/or the developer to suffer death from redundancy :-)
I want to add some perspective.
I have a JS application, with an underlying PHP API connecting my application with data from a third
party data source. The application will make a large number of simultaneous and asynchronous
requests when initalized â to fetch data for multiple application panels. Each panel requires
its own data set, some of which might be overlapping, each of which will also be updated
asynchronous during application use/interaction.
To achieve a reasonable initialization time and good runtime performance, the application and API
have been designed to fetch and deliver data based on the actual need of the individual panel that
makes the request. I only write this because my technical problem could be solved by either
transferring all data in one request, or by making the initialization process synchronous â
thus entirely controlling the timing of data assembly and session writing. However this would be
unbearably slow, compared to the currently implemented design.
The PHP API on my end makes additional requests to a third party API elsewhere on the internet, thus
response-time is unpredictable. Each request from the JS app to my PHP API causes some values to be
stored in the user session. That means I have several scripts running at the same time, reading and
writing the session values. It is the writing part the poses the problem. Each script opens a
session and potentially changes data â but they do not know what data the other scripts update
in the session.
Without using session_start and session_write_close every time a value is updated, then it will be
the session values of the script that finishes last that wins. The session variable of the last
script knows nothing of what the other scripts added, and its smaller version of the truth will be
saved, thus overwriting any data the other scripts already added to the session.
When using session_start() and session_write_close() continuously the scripts will actually use a
shared and continuously updated session, and not just the one they started out with. Sweet. But then
currently that means a large amount of identical Set Cookie headers that will eventually crash the
browsers. Not so sweet.
I currently solved this by rewriting my headers on every session_start to prevent duplicate cookies.
But that is an unnecessary overhead â a forced addition of the set cookie header and then
cleaning up afterwards.
Thus â adding a session_write_open function that does not add a cookie would be a good,
performance optimizing feature that would make PHP stronger. Let's call it a feature :-)
Previous Comments:
------------------------------------------------------------------------
[2022-05-26 08:05:29] chumairasalsabila at gmail dot com
????
------------------------------------------------------------------------
[2015-08-10 20:07:13] 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
------------------------------------------------------------------------
[2011-11-20 05:22:00] danielc at analysisandsolutions dot com
I mean to say, see also: https://bugs.php.net/bug.php?id=38104
------------------------------------------------------------------------
[2011-11-20 05:21:02] danielc at analysisandsolutions dot com
See also: https://bugs.php.net/bug.php?id=31455
------------------------------------------------------------------------
[2010-10-15 23:26:30] 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.
------------------------------------------------------------------------
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=31455
--
Edit this bug report at https://bugs.php.net/bug.php?id=31455&edit=1