ID: 19022
Comment by: allan at emeraldforest dot com
Reported By: phpbugs at mx4k dot com
Status: No Feedback
Bug Type: Session related
Operating System: linux (rh7.3), apache 1.3.26
PHP Version: 4.2.2
New Comment:
I have been experiencing the same (or very similar) problem. One
interesting thing that I found is that sometimes I can reload page A and
see the session data happily sitting there, but on page B the data is
not there. I have both pages open in tabs in Firefox and I can go back
and forth reloading the pages. Page A always has the data, page B never
does. Both pages require the same init.php script to start the session.
Previous Comments:
------------------------------------------------------------------------
[2007-01-03 21:49:22] stranger at teuton dot org
I just started encountering this problem today, after having upgraded
to PHP5 from a PHP4 app. As with some of the other reports I have some
users reporting constant problems, while others have no problems at
all.
I using Linux, with session files written to /tmp. I can see that many
session files are being written, but at the same time some session calls
produce errors. I do not use any session function in my code other than
session_start()
------------------------------------------------------------------------
[2004-07-12 03:02:26] oliver at veryhip dot com
i have the same bug, however, it seems my windows xp box with ie6.0
handles it well, possibly because of the double cookie values being
handled properly? i was using my site for a few months, wandering why
people weren't signing up, then i used my site on my living room
computer and got errors. i have windows 2k and ie5 on it. i get no
errors with netscape 7.0 or mozilla or firefox either. so, if you ask
me: i don't use the php pear rep for the same reason that I'm about to
code my own class for handling sessions. i hate managing a large code
repository of my own, but the only thing that annoys me more is not
understanding what is wrong because of some strange error.
------------------------------------------------------------------------
[2004-05-18 07:01:46] oliver at veryhip dot com
the sessions on my system sometimes look like this:
68.217.0.206.276341084854774671
it's like the php isn't md5'ing the data or something to make the
session. i would assume that maybe php is looking for file:
/tmp/sess_68.217.0.206.276341084854774671 instead of the
/tmp/sess_md5(68.217.0.206.276341084854774671 ) or base64 or whatever
php encodes the session to. if i'm right about this, it wouldn't be
able to read the session because it's looking for another file cause
it's not encoding the session variable right... i get this in my apache
logs, which gets put in my sql database. as i log the cookies in apache
logs, i had to reformat my sql tables to store 255 chars instead of
32... i need to know how to fix this. it happens randomly and i can
only wait till it screws up so i can try to fix it... please email me if
you find a fix!!!! thanks =]
------------------------------------------------------------------------
[2004-04-03 07:10:23] nicolas at swarm dot cc
Hi guys,
i experienced the same problem since 3 weeks.. my session dies after
the current request...
after some investigations:
php sends a wrong "Set-Cookie" header in the HTTP request.. maybe due
to the load.. i'm not sure
==================================================
GET / HTTP/1.0
Accept: */*
Referer: my_host
Accept-Language: fr-ch
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: my_host
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Sat, 03 Apr 2004 11:23:42 GMT
Server: Apache
X-Powered-By: PHP/4.3.3
Set-Cookie: PHPSESSID=50f49658391ab2bfd84ab11baf7b124c; expires=Tue,
23-Sep-1902 09:55:18 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
==================================================
as you can see, the date is wrong .. i made my test today (4th April)
.. mmmh.. i wasn't born when the cookie died :)
i made a very straightforward workaround that is to backup the session
id and restore it as needed..
you can simply cut & paste the following code
<?
// restore the backup cookie
if (isset($_COOKIE["PHPSESSIDBK"])) {
$_COOKIE["PHPSESSID"] = $_COOKIE["PHPSESSIDBK"];
}
// start the session as usual
session_start();
// create the backup if needed
if (!isset($_COOKIE["PHPSESSIDBK"])) {
header("Set-Cookie: PHPSESSIDBK=".session_id()); // you can add
the expiry date if you want
}
?>
i tried this and it works fine.. there's maybe some smarter to do.. but
that way it works..
i hope it will also help the php team to find out what happens... the
only reason i can see is server-load.. on my dev server it never
happened..
so .. let's go back to work :)
------------------------------------------------------------------------
[2004-04-02 12:01:59] phpbugs at chime dot tv dot cutthis
I'm losing session variables randomly too. Sometimes I get the "Failed
to write..." error but not always.
Since I don't host my servers I can't give full server details. However
here's a test script on both servers with the relevant PHPInfo:
Server A: http://chir.ag/test.php
Server B: https://secure.magictanorders.com/test.php
Test script:
<?php
session_cache_expire(30);
session_start();
if($_SESSION["test"] == 1)
{
echo "<center>Sessions work.</center><br><br>";
}
else
{
$_SESSION["test"] = 1;
echo "<center>Starting Session... Click refresh to see if the
session works or not.</center><br><br>";
}
phpinfo();
?>
Basically Server A works ALWAYS and remembers the session for upto 30
minutes. Server B randomly forgets the session in 1 second to 5 minutes.
No session on Server B lasts more than 5 minutes.
The problem randomly started on Server B yesterday (Apr 1). We thought
it was output_buffering (and turned it ON) but that didn't help. Problem
was back this morning. The site was working perfectly for 3 weeks before
breaking down randomly. If anyone can give any suggestions I will be
very thankful.
------------------------------------------------------------------------
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
http://bugs.php.net/19022
--
Edit this bug report at http://bugs.php.net/?id=19022&edit=1
