Solved

Session error causes lockup until you delete PHPSESSID

Posted on 2008-10-24
18
854 Views
Last Modified: 2013-12-13
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();" after "session_start();" so that every time a new page is loaded it would generate a new PHPSESSID cookie.  Before I uploaded the change I opened the "cookie browser" in Firefox and highlighted the PHPSESSID cookie, so I could see if the cookie changed.

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!!!
0
Comment
Question by:abrandpro
  • 10
  • 8
18 Comments
 
LVL 13

Expert Comment

by:Xyptilon2
ID: 22802760
Perhaps.. in some cases, your cookie doesn't contain the domainname information, which per RFC 2109 is required. Add this at the top of the page

<?PHP
if (isset($_SERVER['HTTP_HOST'])) {
$domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
if (count(explode('.', $domain)) > 2) {
ini_set('session.cookie_domain', $domain);
}
}
?>

If that doesn't work, what are the modules that are enabled in your configuration?
0
 

Author Comment

by:abrandpro
ID: 22805747
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
0
 
LVL 13

Expert Comment

by:Xyptilon2
ID: 22806279
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.
0
 

Author Comment

by:abrandpro
ID: 22810442
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.  :-)
0
 
LVL 13

Expert Comment

by:Xyptilon2
ID: 22810492
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?


0
 

Author Comment

by:abrandpro
ID: 22810609
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.
0
 
LVL 13

Accepted Solution

by:
Xyptilon2 earned 500 total points
ID: 22810711
I found and read the thread, unfortunately i didnt get any insights from there. However it would be interesting to determine if the bug only occurs during so-called "peak hours" or do you experience the bug at any time of the day.

Perhaps the problem is due to the following.

A session variable is not set, until the page has finished loading (if i remember correctly). If the user is redirected (for example with a header() call), the end of the script is never reached causing the variabele not to be set. Perhaps if the variabele is not set, other code locks up?

Another possibility is that the issue is Apache related. You're running 1.3, perhaps 2.2 would solve the problem

After thinking about it some more, if it works after manually cleaning the cookies and temporary files, perhaps something is wrong with the headers of the pages. Make sure there are no caching references in the headers of the pages, perhaps this confuses browsers sometimes. with the dynamic nature of the site i assume what you want is for new pages to be retrieved all the time. To do this, you can use

<?PHP
header('Cache-Control: no-cache');
header('Expires: Fri, 10 Aug 2001 03:33:33 GMT');
header('Pragma: no-cache');
?>

If your hosting provider uses some proxy (or an ISP), perhaps this could conflict as well.

In Apache's httpd.conf, have a look at the "CacheNegotiatedDocs" directive, it may be relevant to you.

If all fails, try output buffering before the session starts and flush the output when the page continues like this:

<?php
ob_start();
session_start();

header('Cache-Control: no-cache');
header('Expires: Fri, 10 Aug 2001 03:33:33 GMT');
header('Pragma: no-cache');

/*
* Requires / includes
*/

ob_end_flush();

/*
* Script continues.
*/
?>

0
 

Author Comment

by:abrandpro
ID: 22819085
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!  :-(
0
 

Author Comment

by:abrandpro
ID: 22860369
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?
0
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 
LVL 13

Assisted Solution

by:Xyptilon2
Xyptilon2 earned 500 total points
ID: 22860444
Well, perhaps, though I'm not sure how output buffering is going to solve your problem, have you considered storing session variabels in cookies instead of urls' or vica versa?
0
 

Author Comment

by:abrandpro
ID: 22860550
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.
0
 

Author Comment

by:abrandpro
ID: 22883973
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. :-(
0
 
LVL 13

Expert Comment

by:Xyptilon2
ID: 22884004
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?
0
 

Author Comment

by:abrandpro
ID: 22991691
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.  :-)
0
 
LVL 13

Expert Comment

by:Xyptilon2
ID: 22991710
Glad to hear that, however i do wonder why output buffering seemingly solves the problem. If ever you find out, do let me know :)
0
 

Author Comment

by:abrandpro
ID: 22991880
Well, you're the one who suggested it! :-)  (see post 22810711)
0
 
LVL 13

Expert Comment

by:Xyptilon2
ID: 22991921
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 ...
0
 

Author Comment

by:abrandpro
ID: 23011067
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?
0

Featured Post

What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

Join & Write a Comment

Suggested Solutions

Foreword (July, 2015) Since I first wrote this article, years ago, a great many more people have begun using the internet.  They are coming online from every part of the globe, learning, reading, shopping and spending money at an ever-increasing ra…
Things That Drive Us Nuts Have you noticed the use of the reCaptcha feature at EE and other web sites?  It wants you to read and retype something that looks like this.Insanity!  It's not EE's fault - that's just the way reCaptcha works.  But it is …
The viewer will learn how to count occurrences of each item in an array.
The viewer will learn how to create and use a small PHP class to apply a watermark to an image. This video shows the viewer the setup for the PHP watermark as well as important coding language. Continue to Part 2 to learn the core code used in creat…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now