Edit report at https://bugs.php.net/bug.php?id=38104&edit=1

 ID:                 38104
 Comment by:         andries dot malan at gmail dot com
 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
 Type:               Bug
 Package:            Session related
 Operating System:   any
 PHP Version:        5.1.4
 Block user comment: N
 Private report:     N

 New Comment:

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


Previous Comments:
------------------------------------------------------------------------
[2011-11-20 05:22:52] danielc at analysisandsolutions dot com

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

------------------------------------------------------------------------
[2011-11-09 18:34:52] rfunk at funknet dot net

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.

------------------------------------------------------------------------
[2011-02-04 17:00:58] vdklah at hotmail dot com

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.

------------------------------------------------------------------------
[2006-07-14 20:46:11] il...@php.net

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.

------------------------------------------------------------------------
[2006-07-14 10:23:58] m dot v dot veluw dot smscity at gmail dot com

Description:
------------
When using session_start() and session_write_close() with the same session 
id/name will add multiple session cookies with the exact same contents 
everytime session_start is used.

This is useless overhead if it is the same.

Reproduce code:
---------------
session_name('uniqueName1');
session_start();
$_SESSION['Foo1'] = 'Bar1';
session_write_close();

session_name('uniqueName2');
session_start();
$_SESSION['Foo2'] = 'Bar2';
session_write_close();

session_name('uniqueName1');
session_start();
$sessionValue = $_SESSION['Foo1'];
print $sessionValue;
session_write_close();

session_name('uniqueName2');
session_start();
$sessionValue = $_SESSION['Foo2'];
print $sessionValue;
session_write_close();

Expected result:
----------------
just 1 session cookie header for uniqueName1.

just 1 session cookie header for uniqueName2.

Actual result:
--------------
2 session cookie headers for uniqueName1, where both are exactly the same

2 session cookie headers for uniqueName2, where both are exactly the same


------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=38104&edit=1

Reply via email to