Session error causes lockup until you delete PHPSESSID
I run a social networking website that's built on PHPFox version 1.5.1 (running on PHP 4.4.4 with the APC extension and Apache 1.3.33) . I have a serious problem regarding sessions, which unfortunately I am unable to duplicate, making it very hard to solve. Here's what happens...
You'll be surfing the site fine, then all of a sudden things will sort of "lock up" and it won't load any more pages. In Firefox it just says connecting to http://mysite.com, but in IE it will actually give you a "page cannot be displayed" error, as if it's unable to connect to the server. If you go into your cookies and delete the PHPSESSID cookie then everything is back to normal and the site loads fine.
I have very rarely experienced the bug myself. Perhaps five times in the past six months. However some of my visitors seem to experience it more often. I have one guy who says he consistently gets the error after surfing the site for only a couple minutes. Luckily, I'm able to use this guy for testing, at least when he feels like answering my e-mails.
I had him surf on my development site, which is running the exact same code as the live site. He said he got the error but it took about 30 minutes before it happened, instead of two. So it could possibly have something to do with the amount of traffic the site is getting (approximately 20,000 unique today) however the development site and live site are hosted on the same server, so it must not be a server load thing
I actually just got the error myself, in Firefox, which allowed me to do a little bit of tweaking/testing. Basically I was doing some administrative work on the site, clicked a link, and the page would not load. After I determined that my connection was fine, and that my site was still up and could be accessed through IE, I realized this was the dreaded session bug. When I would click refresh, or try to access any other page on the site, the status bar of the browser would say "Connecting to mysite.com" and then "waiting for mysite.com" but then just hang there.
My knowledge of PHP is very limited, but from reading the manual one thing I decided to try was to add "session_regenerate_id();"
I uploaded the updated file, and prayed that when I clicked my refresh button the page loaded, but no dice. :-( When I looked at the cookie I saw that it was not changing. I started looking into what else I might try, but within five minutes I saw that the page was now loading, and the cookie was now changing with every new request. I'm not sure why it suddenly started working, but it seems to me that the session_regenerate_id() command had no effect.
Any help with this problem would be greatly appreciated!!!
You'll be surfing the site fine, then all of a sudden things will sort of "lock up" and it won't load any more pages. In Firefox it just says connecting to http://mysite.com, but in IE it will actually give you a "page cannot be displayed" error, as if it's unable to connect to the server. If you go into your cookies and delete the PHPSESSID cookie then everything is back to normal and the site loads fine.
I have very rarely experienced the bug myself. Perhaps five times in the past six months. However some of my visitors seem to experience it more often. I have one guy who says he consistently gets the error after surfing the site for only a couple minutes. Luckily, I'm able to use this guy for testing, at least when he feels like answering my e-mails.
I had him surf on my development site, which is running the exact same code as the live site. He said he got the error but it took about 30 minutes before it happened, instead of two. So it could possibly have something to do with the amount of traffic the site is getting (approximately 20,000 unique today) however the development site and live site are hosted on the same server, so it must not be a server load thing
I actually just got the error myself, in Firefox, which allowed me to do a little bit of tweaking/testing. Basically I was doing some administrative work on the site, clicked a link, and the page would not load. After I determined that my connection was fine, and that my site was still up and could be accessed through IE, I realized this was the dreaded session bug. When I would click refresh, or try to access any other page on the site, the status bar of the browser would say "Connecting to mysite.com" and then "waiting for mysite.com" but then just hang there.
My knowledge of PHP is very limited, but from reading the manual one thing I decided to try was to add "session_regenerate_id();"
I uploaded the updated file, and prayed that when I clicked my refresh button the page loaded, but no dice. :-( When I looked at the cookie I saw that it was not changing. I started looking into what else I might try, but within five minutes I saw that the page was now loading, and the cookie was now changing with every new request. I'm not sure why it suddenly started working, but it seems to me that the session_regenerate_id() command had no effect.
Any help with this problem would be greatly appreciated!!!
ASKER
Thanks for the feedback! I don't think the domain name information is the problem for two reasons. First, the few times that I've experienced the bug myself, I've gone into my cookies and looked at the PHPSESSID cookie and it's always had the correct domain name for the host. Secondly, if this were the problem, then I would think the bug would occur on their second page request, since the cookie would have been set on the initial request. But instead the bug randomly appear after many pages have already been viewed. Does this sound like a correct assumption to you?
I'm attaching both my php.ini and my http.conf files so you can see exactly how things are configured.
Thanks again for the help! :-)
php.ini.txt
httpd.conf.txt
I'm attaching both my php.ini and my http.conf files so you can see exactly how things are configured.
Thanks again for the help! :-)
php.ini.txt
httpd.conf.txt
Your configuration files don't show anything strange or out of place. Do you server logs give you any information? most notably the /var/log/apache/error_log ? Would you mind giving the url of the site if it is worldwide accesibble and i'll see if i can reproduce the problem here.
ASKER
I asked my hosting company for help with this issue a couple weeks ago, and they looked at my server logs and couldn't find anything out of the ordinary. I even gave them the IP address of the user I referred to earlier who is able to consistently duplicate the bug, but they could not find anything strange when they filtered the logs using that IP. They did recommend that I try upgrading to PHP 4.9, as well as updating the APC extension and Apache. All of which I plan on doing, but even they admitted that this is unlikely to solve the problem.
I don't mind posting the URL, but I hope I don't scare you away! The site is dick.net. It's an adult website, mostly populated by gay men. I've never been able to duplicate the bug, but feel free to try, if you're up for it. :-)
I don't mind posting the URL, but I hope I don't scare you away! The site is dick.net. It's an adult website, mostly populated by gay men. I've never been able to duplicate the bug, but feel free to try, if you're up for it. :-)
I looked at your website, (the name is quite descriptive) and was unable to reproduce the bug you mentioned while browsing the site (without a login), I tried in Chrome, IE8 and FF3. Have you been able to isolate the bug to a specific browser, the bug may (after all) be on the client-side instead of the server-side. I've not been able to test it in other browsers. I'm on the WinXP SP2 platform.
I don't think upgrade the APC extension in Apache will make much difference, but perhaps upgrade PHP does, by the way, why not to 5.2?
I don't think upgrade the APC extension in Apache will make much difference, but perhaps upgrade PHP does, by the way, why not to 5.2?
ASKER
Glad I didn't freak you out! :-)
I know that the bug occurs in IE7, IE8, FF2, and FF3, whether or not you are logged in. Not sure about the other browsers. I had one user that said the problem stopped when he switched to Safari, but then another user said that he gets the problem regardless of whether he is using Firefox or Safari. As I mentioned in my original post, there is a difference in the way the bug presents itself between IE and Firefox. In Firefox, it just hangs with a blank page and "connecting to dick.net" in the status bar. However in IE, you get a "Page cannot be displayed" error, as if the site were off-line, or you weren't connected to the internet.
A huge percentage of my members have experienced this issue, including myself. So I don't think it's a client-side thing. I'm on Vista by the way.
There is a thread in the help forum on my site regarding this issue, which might give you some insight. You can find it by searching for "connectivity issues". I'd rather not link to it here because of the nature of my site. :-)
I'm nervous about going above PHP 4.9 because I'm afraid it might break my site because of compatibility issues, since PHP is not necessarily backward-compatible. I figure as long as I stay in 4.X I'll probably be fine. Aside from PHPFox I'm also using vBulletin and several other third-party packages.
I know that the bug occurs in IE7, IE8, FF2, and FF3, whether or not you are logged in. Not sure about the other browsers. I had one user that said the problem stopped when he switched to Safari, but then another user said that he gets the problem regardless of whether he is using Firefox or Safari. As I mentioned in my original post, there is a difference in the way the bug presents itself between IE and Firefox. In Firefox, it just hangs with a blank page and "connecting to dick.net" in the status bar. However in IE, you get a "Page cannot be displayed" error, as if the site were off-line, or you weren't connected to the internet.
A huge percentage of my members have experienced this issue, including myself. So I don't think it's a client-side thing. I'm on Vista by the way.
There is a thread in the help forum on my site regarding this issue, which might give you some insight. You can find it by searching for "connectivity issues". I'd rather not link to it here because of the nature of my site. :-)
I'm nervous about going above PHP 4.9 because I'm afraid it might break my site because of compatibility issues, since PHP is not necessarily backward-compatible. I figure as long as I stay in 4.X I'll probably be fine. Aside from PHPFox I'm also using vBulletin and several other third-party packages.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the suggestions! I'm going to implement these one by one and hopefully one will do the trick. :-) Unfortunately, my "guinea pig" is out of town right now so it will probably be a few days before I can get him to test the changes. Will post here when I have a result.
It really sucks trying to debug something that you're not able to duplicate! :-(
It really sucks trying to debug something that you're not able to duplicate! :-(
ASKER
Well, I had my hosting company upgrade PHP to 5.2, after I reviewed all my scripts and determined that they were supposedly all compatible with PHP five. They also upgraded Apache and the APC extension. Unfortunately, it seems that I have jumped right out of the frying pan directly into the fire. It didn't fix the bug in question, and now I'm having even more problems that all seem to center around PHP sessions.
I've received a bunch of complaints from users that they are unable to log in and/or unable to use the contact form to report the bug. After looking at the code it seems that both of these errors are caused by a lack of a session variable being set. I'm unable to duplicate either of these errors myself, trying several browsers on both XP and Vista. Many users are able to log in without a problem. I'm consulting with my hosting company about possibly rolling back the upgrades to the previous versions.
I will probably try output buffering next. Do you think I'd be better off enabling this feature through php.ini?
I've received a bunch of complaints from users that they are unable to log in and/or unable to use the contact form to report the bug. After looking at the code it seems that both of these errors are caused by a lack of a session variable being set. I'm unable to duplicate either of these errors myself, trying several browsers on both XP and Vista. Many users are able to log in without a problem. I'm consulting with my hosting company about possibly rolling back the upgrades to the previous versions.
I will probably try output buffering next. Do you think I'd be better off enabling this feature through php.ini?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Didn't you suggest I try output buffering in an earlier post?
Right now the session ID is stored in a cookie, rather than via URLs. To switch would require a huge amount of coding. I'd probably just get rid of sessions altogether and store all the data in cookies, rather than adding the session ID to every link on the site without knowing that it would definitely solve the problem.
Just to be clear, the "lock up" for which I posted this question is resolved when you delete the PHPSESSID cookie, without clearing any of the other files in the cache. Luckily, in most cases, uses can achieve this by simply closing and re-opening their browsers, since the PHPSESSID cookie is set to expire at the end of the session.
Right now the session ID is stored in a cookie, rather than via URLs. To switch would require a huge amount of coding. I'd probably just get rid of sessions altogether and store all the data in cookies, rather than adding the session ID to every link on the site without knowing that it would definitely solve the problem.
Just to be clear, the "lock up" for which I posted this question is resolved when you delete the PHPSESSID cookie, without clearing any of the other files in the cache. Luckily, in most cases, uses can achieve this by simply closing and re-opening their browsers, since the PHPSESSID cookie is set to expire at the end of the session.
ASKER
Just an update. I've fixed all the bugs that resulted from the upgrade to 5.2, but unfortunately the original timeout bugs still persists. :-(
Sorry for the late reply, normally i reply to comments in threads i participate in. So the upgrade to PHP 5.2 did not solve the problem.
The error is not specific to a browser or a time-out (based on your comments), but seems to be triggered when the browser (for some reason) is unable to update the PHPSESSID cookie.
I doubt this is a permission problem, it may also not be a server problem, perhaps those users have anti-spyware programs installed? real-time scanners are known to have the potential to interfere? Can you rule this out as a cause?
The error is not specific to a browser or a time-out (based on your comments), but seems to be triggered when the browser (for some reason) is unable to update the PHPSESSID cookie.
I doubt this is a permission problem, it may also not be a server problem, perhaps those users have anti-spyware programs installed? real-time scanners are known to have the potential to interfere? Can you rule this out as a cause?
ASKER
Sorry for the delay. If I received an e-mail notification for your last reply, then I must've deleted it without knowing.
I don't think it's an anti-spyware issue, and I'm not even sure what real-time scanners are, however I enabled output buffering, and I think that may have fixed the problem. At least I haven't had any complaints since I did. Once I know for sure that the problem is fixed I'll happily close this thread. :-)
I don't think it's an anti-spyware issue, and I'm not even sure what real-time scanners are, however I enabled output buffering, and I think that may have fixed the problem. At least I haven't had any complaints since I did. Once I know for sure that the problem is fixed I'll happily close this thread. :-)
Glad to hear that, however i do wonder why output buffering seemingly solves the problem. If ever you find out, do let me know :)
ASKER
Well, you're the one who suggested it! :-) (see post 22810711)
Yes i know lol...I'm just trying to recall what my reasoning was. Perhaps because with output buffering the content is written to the browser always after all headers are sent and sessions utilize session cookies which are written in the headers also ...
ASKER
Well, apparently the problem persists. :-( Another problem that's happening, which might be related, is some users are complaining that the site is extremely slow. However, when these same users use a web-based tool to test the speed of the site, the results always show that the pages load in less than a second. Some of these users have found that the slowness occurs in IE, but not when they're using Firefox.
The user I described in an earlier post, who is able to consistently duplicate the timeout bug, has also complained that the site is slow. When I told him to try Firefox instead, he said that it's faster, but the timeout bug occurs much quicker. When using Internet Explorer, the site is slow but he can make it about a half-hour before the timeout bug occurs. When he's using Firefox, the site is quicker but the error occurs within a few minutes.
Does that make any sense to you?
The user I described in an earlier post, who is able to consistently duplicate the timeout bug, has also complained that the site is slow. When I told him to try Firefox instead, he said that it's faster, but the timeout bug occurs much quicker. When using Internet Explorer, the site is slow but he can make it about a half-hour before the timeout bug occurs. When he's using Firefox, the site is quicker but the error occurs within a few minutes.
Does that make any sense to you?
<?PHP
if (isset($_SERVER['HTTP_HOST
$domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
if (count(explode('.', $domain)) > 2) {
ini_set('session.cookie_do
}
}
?>
If that doesn't work, what are the modules that are enabled in your configuration?