|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45270 session_start() incorrectly tries to send a cookie
Submitted: 2008-06-14 14:05 UTC Modified: 2008-07-11 15:57 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: vesselin dot atanasov at gmail dot com Assigned:
Status: Not a bug Package: Session related
PHP Version: 5.2.6 OS: Fedora Core 8
Private report: No CVE-ID: None
 [2008-06-14 14:05 UTC] vesselin dot atanasov at gmail dot com
session_start() incorrectly tries to send a cookie even when it has already been sent. This causes problems with sessions that are closed with session_write_close() some output has been sent and then the session is re-opened with session_start()

The second time when session_start() is called it should avoid sending the cookie and cache headers, since they have already been sent by the first call to session_start(). It seems that the second time session_start() tries to send the same cookie value as the first time, so it should be possible to avoid sending that cookie a second time.

Reproduce code:
session_start ();
session_write_close ();
print ("Test");
session_start ();

Expected result:
No output at all.

Actual result:
Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /var/medical/htdocs/try.php:4) in /var/medical/htdocs/try.php on line 5

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/medical/htdocs/try.php:4) in /var/medical/htdocs/try.php on line 5


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-08 13:30 UTC]
Why would you stop and start a session in same request? It's by design like this..
 [2008-07-08 15:16 UTC] vesselin dot atanasov at gmail dot com
Hello Jani,
Once a PHP process/thread starts a session, it acquires an exclusive lock of the session variables. This means that a different PHP process/thread cannot start a session while the first process is working. This turns out to be a problem for websites that provide some kind of API. Let's assume that our API has two kinds of calls:
A) Ones that take more or less long time, e.g. 5-10 minutes.
B) Ones that take a sort time, e.g. 1-2 seconds.

So here is what a long web API call should look like:
1. Start the session (acquire an exclusive lock of the session data).
2. Read some session variables.
3. Close the session (release the exclusive lock).
4. Do some long processing for 5-10 minutes.
5. Write the processing result to standard output, effectively sending it to the client that called the API.
6. Start the session again (acquire the exclusive lock again).
7. Write some state variables back to the session data.
8. Terminate the PHP script.

So from this sequence it is obvious that in step 4 many short API calls can be performed while the long processing takes place. If we cannot stop the session, releasing the lock and then start it again, we need to hold the lock for 5-10 minutes thus serializing access to the API, which is pretty inefficient.
 [2008-07-11 15:57 UTC]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

See bug #45380 which has a bit more info.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Feb 25 02:01:23 2021 UTC