php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #45270 session_start() incorrectly tries to send a cookie
Submitted: 2008-06-14 14:05 UTC Modified: 2008-07-11 15:57 UTC
Votes:2
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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: vesselin dot atanasov at gmail dot com
New email:
PHP Version: OS:

 

 [2008-06-14 14:05 UTC] vesselin dot atanasov at gmail dot com 
Description:
------------
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:
---------------
<?php
session_start ();
session_write_close ();
print ("Test");
session_start ();
?>


Expected result:
----------------
No output at all.

Actual result:
--------------
Test
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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-08 13:30 UTC] jani@php.net 
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] jani@php.net 
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-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 22:01:28 2024 UTC