426180 - PHP Session_Start() with Firefox for Mac causes site to be unavailable

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Mark Hughes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032605 Firefox/2.0.0.11 24892
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

As seen elsewhere on the Internet but without resolution.

We have a site that will occasionally cause Firefox Mac to crash. Following such a crash, the user can navigate and use other sites - and can even use the same site if they visit alternative URL's (eg, non-WWW instead of WWW-) but the same crash is likely. This has happened on two such sites but not on others; most of our sites use Sessions and all three of our designers (all on Macs) have checked and experienced this issue.

Mac versions vary and the problem has existed for at least the last few (minor) versions of Firefox 2.0; not sure about previous versions, although online other people have seen this since 1.5.

PHP is 5.2.3. Apache is 2.2.6. 

Unfortunately the only offending site is currently restricted to private viewing whilst in development - please e-mail me directly with your IP address and I'll happily add you on to the list, but we don't want search engines spidering a site in development yet!

Reproducible: Sometimes

Steps to Reproduce:
1. Visit my site
2. Keep visiting
3. Just maybe it'll crash (on Mac) - sometimes not. We have seen certain pages that crash more frequently than others, but these pages are product pages and do not vary at all in format or content (except wording; nothing else special though) from the ones that work
Actual Results:  
Firefox stalls on that web site and will not keep working on that site until being fully closed down and re-opened

Expected Results:  
Firefox stalls on that web site and will not keep working on that site until being fully closed down and re-opened

Although this is (perhaps?) relatively rare and probably not of huge priority, for the sites it affects it is a major bug (assuming it is a Firefox bug; which I have every reason to believe judging from the circumstances) as it will prevent Mac users reliably using the site and others with the same problem.

Safari also works perfectly with this, as does Internet Explorer and Firefox on PC.

Comment 1

[Matthias Versen [:Matti]]

Since your page is restricted and it's only sometimes and requie a mac to test, this is currently a little bit difficult for us testers here.

You may want to try the Firefox3 Beta4 which will be soon replace Firefox2.
 

Comment 2

[Mark Hughes]

Hi Matthias,

I personally use Firefox3 on my PC's, but I was under the impression that FF3 would not become mainstream until June or later? If that is the case this is still a major problem as it prohibits the use of this site with Mac FF2.

It is occasional but I believe certain pages cause it more frequently, and it seems to be frequent enough that it is reproducible.

Comment 3

[Matthias Versen [:Matti]]

I say it straightforward, this seems to be rare given that we have no other ( i could not find) report about such an issue. The whole Firefox2.x gets at this point more or less only security fixes and fixes for ugly regressions.

It's to critical to fix other things in this "old" branch because you can very easy get major regressions.

The problem itself must be analyzed to get more information about this problem...

Did you try a shift+reload ?
Did you try to use file/work offline and back to online ?
 

Comment 4

[Mark Hughes]

Matthias,

I understand not wishing to fix this 'old' branch - but as the new version doesn't have a solid release date (AFAIK?) this is still a very important bug.

It certainly has been seen before - however, most people probably wouldn't know why they're seeing it, so knowing it's a combination of Sessions, Firefox and Mac is at least quite fortunate.

We have narrowed down to a few pages that cause the problem very frequently - sometimes every time - so at least seeing the problem is very possible.

Shift+Reload and Offline/Online does not work; it's completely locked up on the entire site, no matter what page you try and visit. This could - perhaps - by simply a side-effect of still using Sessions per page; perhaps a request is being made.

In fact I believe this to be the case; I used Live HTTP Headers extension and did see the full requests being made; so it's stopping after getting at least a basic response.

Comment 5

[timeless]

ok. this isn't a crash. if you don't get talkback, crashreporter or the os crash reporter then you didn't crash. you just have some problem. please refrain from using the word crash.

http://www.mozilla.org/projects/netlib/http/http-debugging.html

try using about:config

you can try setting some of these to false:
network.http.keep-alive
network.http.proxy.keep-alive
network.http.pipelining.ssl

and you can try increasing these:
network.http.max-connections-per-server
network.http.max-persistent-connections-per-server

Comment 6

[Mark Hughes]

A "Stall" then - either way it's very clearly a Firefox bug and one that needs resolving - and waiting for the FF3 is simply not an option with FF2 being as prevalent as it is.

I've set those top three values; with both keep-alive's disabled it appeared to work - but now is repeating the original problem.

Increasing the connections did not make any visible difference however.

Comment 7

[Thomas K. (:tom)]

The problem is primarily with the subject here.  PHP is a server side language, meaning your server does some stuff before sending the data to Firefox.  Since "session_start()" means little in this case, if you can find out which kind of pageload does it (what parameters set, if it's a certain forums post or something), then save that page to an html file and attach it, it'd help a lot more.

It's called a "testcase", though, and the goal is to narrow it down to just the part of the page that's causing the problem.  Here's a guide:
http://quality.mozilla.org/litmus/create-testcases

Comment 8

[Mark Hughes]

Hi again,

Tom - I'm aware of "testcases" - unfortunately this is extremely hard to produce as the problem does not rear its ugly head in the testcases I've created! However...

The URL to the site is: http://tinyurl.com/4gnfj3 (Please leave as a TinyURL because I do not want sensitive data about the site being discussed with the direct URL)

My findings:
It's a COOKIE problem, not directly Sessions! With Cookies disabled the problem disappears, but obviously breaks other things (eg, the shopping cart!). If the session_id(); is changed then the site will stop being locked up, so it's something in the session/cookie for *that* session. 

If the session was continually changed (obviously this is stupid and useless) there would be no problem. If Cookies were disabled and all URL's changed to include the PHP Session ID then the problem is also gone; however this is the biggest PITA to solve as there's dozens of pages with URLs...

I'm going to keep diagnosing the problem further - but now you can see the site (it's gone live yesterday) and now we know it's a cookie problem that helps things.

Comment 9

[Mark Hughes]

Okay - I've solved *my* problem, but I'm still not sure if this is a bug or not - so I'd like to continue with this bug report through to some kind of solution!

What it appears is that my site is sending cookies contained within the images. I.e., session_start(); and later header("Content-type: header/jpeg") [sic] and then the data...

Although nothing else is sent this appears to be what kills it. By selectively *not* sending session_start() if an image is being displayed the problem disappears. However, as before, Internet Explorer and Firefox [PC] are unaffected.

Running the site through a proxy on my PC (Charles Proxy) removes the problem; but that could, perhaps, be because Charles Proxy strips cookies from images? I couldn't tell; unfortunately all my tests using Charles Proxy worked, preventing me from debugging using that!!

So, my main question:
- Is it legal to send cookies with images? Since an image is simply an HTTP request with a certain type of Content-Type I cannot see why not - but am I breaking the accepted rules here? If so, that means captcha's that work with session_start() to track the users ID (for instance) are illegal also?

Thanks,
Mark

Comment 10

[Matthias Versen [:Matti]]

It's of course legal to send a cookie with any kind of a http response AFAIK.
I don't think that Firefox stalls in this case, it seems your server stalls for some reason if Firefox included the cookie in the next request.

That it works after a restart means that the session cookie gets deleted and it works again without the session cookie.
Deleting the session cookie should make it work again and you can also see the current session cookie (content, path etc) in Tools/Options/Privacy/show cookies.
If the page works again after you deleted the session cookie you can generate a packet trace : http://developer.apple.com/qa/qa2001/qa1176.html

Comment 11

[Mark Hughes]

Hi Matthias,

I thought it would be legal, so thanks for the clarification!

It turns out not even the browser needs restarting - so long as the session_id() is reset (server-side; effectively the same as deleting the cookie client-side).

I'm trying to create a testcase based on this new information (ie, it being image related and it being cookie related) - although, again, the test-cases I've created thusfar have failed (to break!). The test case currently does:

<?php
session_start();
Header("Content-type: image/png");
setcookie('abc'.rand(0,10000).'-'.rand(0,10000),'abc'.rand(0,10000).'-'.rand(0,10000),time()+60*60*24*100, "/",'.'.$_SERVER['SERVER_NAME']);
echo file_get_contents('images/about_'.rand(1,8).'.jpg');
?>

(Image PNG despite being JPEG; although tried JPEG. Setting a random cookie to ensure a SetCookie [sic] header is added; and a random JPEG from our images directory just so it's easy to see when a breakage occurs).

This code does not break unfortunately - so I will continue to probe into what, particularly, causes this 'rare' (as it's every x number of page views - sometimes only a few, sometimes a hundred perhaps)...

Cheers
Mark

Comment 12

[Jim Hu]

Anything new on this?  I found this bug while trying to figure out why a PHP script (a mediawiki extension) I'm working on isn't properly setting session data between pageload on FF Mac, but not in Safari.

I'm not sure if it's the same problem, but the behavior is consistent with a session variable being set at the end of a script, and then not being read on the next pageload in the same site.  Instead, php seems to see the value from an older copy of the variable.  

It sounds like something that can be handled by changing my php code, but if someone knows what I need to change, I'd appreciate it.

Comment 13

[Tyler Downer [He/Him]]

This is a mass search for bugs that are in the Firefox General component, are
UNCO, and have not been changed for 800 days and have an unspecified version. 

Reporter, can you please update to Firefox 3.6.10, create a fresh profile,
http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you
still see the bug, please update this bug. If the issue is gone, please set the
resolution to RESOLVED > WORKSFORME.

Comment 14

[Tyler Downer [He/Him]]

No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.