From: [EMAIL PROTECTED] Operating system: redhat 7.3 PHP version: 4.2.3 PHP Bug Type: Session related Bug description: sessions randomly fail
I have seen this bug reported a couple of times. Forgive me for starting my own but I want to bring this back to the attention of the developers. I've got a fairly high traffic server. (30-50K uniques per day) For the most part, everything works ok. We get plenty of orders (between 70-90 a day). However, I also get complaints from people who say they keep losing their cart. To try and track down what was going on. I started storing some fairly simple stats from the site. Here is an example of one sent to me via e-mail from my order.html page. Person's cart failed? Referring url is: http://www.t-shirtking.com/cart.php User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner) Cookie output: c93856925c2ed796d3560d3729ebeb60 Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60 Other Session: addProduct new session is: c93856925c2ed796d3560d3729ebeb60 A quick description is as follows. If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message. It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart) Then I grab the user agent to try and narrow down the browsers with problems. Then I see if the session id is in a cookie. Then, by looking at their session variable, I can see that they went to cart.php via the given url. (I store the http_refferer as a session variable on the cart.php page) Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalog url and did indeed pass the cart command addProduct (via the form post data). As a last test, I send myself the session_id that order.html is using (to make sure the session wasn't restarted) So, what can I gather from this....I only give one example. However, I get about 10 of these messages a day. I'm sure there are even more than that considering that some people may give up when they notice their cart isn't holding their products and don't bother going to order.html. As you can tell from above, it is clear that the session id is indeed intact. Also, I'm actually able to pull information out of the session that was stored on a previous page. (the addProduct command and the url stored in the session by the cart.php page) However, the cart variable, which is an object, is no longer there. (it is a simple object btw. Just an object with an array in it and a few member functions) I thought perhaps using the default php session manager, that it was having problems. So I recently switched it to a mysql based manager. (just using the session_save_handler). I still get the issue though. Therefore, I cancel out blaming php's file storage method. Where is my cart object going? It happens only randomly. It also happens only to users of IE. (though 90% of our traffic are IE users) It happens to IE6.0, IE5.5, IE5.0. It also happens at any time during the day (meaning, high traffic times and low traffic times) I have also been able to immediately look at my sessions table in the database when I receive a message like the above. Sure enough, the session is there...it has data...just no cart. Of course, the biggest problem of all....I can't reproduce the bug to save my life. I've tested on 10 different machines using a variety of Windows versions and IE versions. I've tested the cart well over 100 times. Yet, I never seem to be able to break it. I even try to add the product that I know the person who did lose the cart was trying to buy. I'm pretty sure I'm losing orders because of this. I can't imagine how many people are having issues. I have tried two things in the last couple of days. One, I downloaded and installed the cvs version of PHP. I also stopped storing the cart as an object and simply storing it as an array. Neither of these tests have worked. I still get the problem. Right now, we are going to setup a second server and split the traffic among each. Hopefully this will lower the loss of session data. The other wierd thing is that I don't lose the entire session. Just the part that contains the cart array. (and before that the cart object) Remember, the cart object had the same array in it that I am storing now. Perhaps the problem is with storing arrays??? Anyway, this is a major problem. I've seen it in past bug reports. The fact is, sessions are unreliable. And that is a shame. I see it as mission critical for PHP. If this doesn't get fixed soon, I guarantee that my client will want to move away from php. And that to me would be a nightmare. It is possible that sharing the load on 2 servers will solve my problem. But I shouldn't have to have a second server when one server is perfectly capable of handling the traffic. (my server load hovers between 0 and 2.) My install options are: ./configure --with-apxs=/usr/sbin/apxs --with-config-file-path=/usr/local/lib --disable-debug --with-mysql=/usr I have apache 1.3.23 Here is a link to my phpinfo() function http://www.t-shirtking.com/temp/phpinfo.php Thanks, Josh Bauguss -- Edit bug report at http://bugs.php.net/?id=20449&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20449&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20449&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20449&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20449&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20449&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=20449&r=support Expected behavior: http://bugs.php.net/fix.php?id=20449&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=20449&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=20449&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20449&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20449&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20449&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20449&r=isapi
