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 :)

Okay, no more dirty hacks =)
Marking it as "won't fix" and considering as a feature.

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.

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.

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

I mean to say, see also: https://bugs.php.net/bug.php?id=38104

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

????

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 :-)