User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727) Build Identifier: Firefox 2.0 (Sorry, Il'll Edit When I get back to my PC) Hi All, I am a developer for The Cacti Group (www.cacti.net) and I have recently upgraded to FF2 and unfortunately discovered an error in communications between Apache 2.x and Firefox 2.0 while rendering graphics behind the scenes that causes a) The page to only partially load 2) Stuck process in Apache (aka Hung Server) 3) libpng error in Apache log. This problem is 100% repeatable. It occur's in Windows Firefox and Windows Apache 2.x on the same system (my test box). I would like some guidance as to how to help the Firefox team understand what is happening as this is a bad thing. I don't want FF2 locking up Apache servers out there. If someone can please provide guidance, I will follow your instructions. Whether its installing an non-stripped version of FF2, or turning on DEBUG somehow, I am at your disposal. Regards, TheWitness Developer The Cacti Group Reproducible: Sometimes Steps to Reproduce: 1. Goto Cacti Web Site 2. Goto Graph Management 3. Edit Advanced Ping Graph 4. Turn on Graph Debug 5. Refresh Page Several Time Actual Results: Sometimes, the page refreshes just fine, but within 6-7 attempts to refresh the page, it fails to load 100% and the Apache Server hangs. In the Apache log there is a libpng error. I can not reproduce this problem in Internut Exploiter (v7.0). Expected Results: The page should always return successfully I am available to work with a FF developer to isolate, but need your assistance as setting up test environment.
Really not sure what's going on here... it sounds like a problem with Apache, though. Maybe you can report it to them?
I thought that as well, but for some reason I can't reproduce using any other browser, so that has to be something wrong with the request being sent to the server. I guess I could "sniff" the post with Ethereal/Wireshark using the two browsers and sift through the rubble. If there are any better ways to get to the bottom of this, let me know. Larry
Create a simplified testcase. Perhaps only the special png file is needed to refresh. Then try to sniff the communication. It should be easier. Does the same problem occurs if the apache server is running on another host and not the same machine?
I will have to check. I know that there are two backend call's on the page to the same RRDfile both generating the same graphic. The one that fails in random. So, it may be due to FF forking each of the processes in parallel (aka with multiple client threads) and maybe causing Apache to loose it's mind or FF closing the wrong file descriptor/socket something. In this case, Cacti generates a page that 1) Sends a request to Apache that returns binary data (image) in one case, and forks the same call to the backend, but in the second case return's a simple status string, typically the STDOUT from the RRDtool command. Again, it does not happen in IE7. I'll start to dig in sometime today.
I have confirmed that the apache hanges from both Local/Local (Browser/Server) and Remove/Local (Browser/Server). I attempt to append the sniffer captures (Wireshark format). They are: Ie7.0 - works all the time ff2.0 - working 1 time ff2.0 - working 1 time, followed by hanging server Hmm. I don't see where to post gzip files. Where can I send them?
(In reply to comment #5) > Hmm. I don't see where to post gzip files. Where can I send them? You can add this as attachment to this bug. Simply hit "Create a New Attachment" and attach your gzip file.
Created attachment 248136 [details] This is FF2 working As Expected Here are the three captures that I performed. I was unable to lock up Apache with IE7, but Apache went bonkers with FF2. It looks like it may have to do with the version of HTML. Looks like Apache may not fully support it or something. There are three files. Two that had not issues, and the third showing the lockup. You will see that the browser sends the request and never receives a response from the server. Apache just hands.
Created attachment 248137 [details] This is IE7 Working as Expected Again, IE never locks up Apache.
for the record: any input firefox can give to a web server is input that the webserver *must* accept. not from an RFC clean perspective, but from a security perspective. If firefox can be buggy then someone can emulate the perceived behavior in order to attack you server. whether or not firefox /should/ do whatever it does may be an open question which we may investigate, but you need to fix your server.
Yea, I am thinking that I need to open a ticket with the Apache Foundation as well. Not this week though... Do you guys support xreferencing each others bug ID's? This may only be a Windows server issue as well. Maybe something in the bowels of the Apache code. TheWitness
(In reply to comment #11) > bug ID's? This may only be a Windows server issue as well. Maybe something in > the bowels of the Apache code. To your initial comment. Can you clearly describe the steps how to reproduce it with the newest Cacti version? I cannot find your step 3 "Edit Advanced Ping Graph".
Ok, lets make some assumption: 1) Windows Apache 2) Windows Cacit 3) Install Graph Template "advanced ping template" located here: http://forums.cacti.net/viewtopic.php?t=10049 4) From the consoled "Import Template". You need to import the XML and then place the script in the scripts directory 5) Add the Advanced Ping to a Host, and Create a Graph 6) Wait for the poller to run and create the RRD file. 7) Goto "Graph Management" and View the Graph, make sure it shows. 8) Press the Graph Debug Link in the Top Right of the Page to show the graph logic and output. 9) Now, refresh the page several times as it. It will eventually hang the server.
Is this still an issue? I ask the reporter to get more information but haven't got an answer to my latest questions. I'm not able to setup cacti and run this test. If it is still an problem use a net sniffer and record the send/received data. That would help to identify what's going on here. I also think that's a problem of Apache.
You can close this ticket. The issue was a server issue related to out of band data interfering with in band data. Sorry for not informing you sooner.