I found this similar question here on serverfault, but the answers there don't cover my case (that I can tell).
On some [apparently] random basis, Firefox (only browser I've tried) will try to download a PHP page rather than 'load' it.
Often, closing the download/open dialog and re-clicking the link will make it work properly. Sometimes, I need to bounce Apache.
This is annoying not only to myself, but to others who use my server. Any idea as to what could be causing this?
Output of top:
(mysqld runs anywhere from 1% to 190% on this server, but I have not noticed a correlation between its spikes and Apache flaking out on whether to offer a PHP page for "opening" and just running it like it should.)
top - 15:37:38 up 44 days, 10:17, 1 user, load average: 0.11, 0.37, 0.43
Tasks: 39 total, 2 running, 37 sleeping, 0 stopped, 0 zombie
Cpu0 : 94.6% us, 5.4% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 94.9% us, 5.1% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1474560k total, 1464856k used, 9704k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3698 mysql 15 0 124m 28m 4348 S 187.0 1.9 5:26.25 mysqld
11286 root 15 0 3552 880 656 S 1.6 0.1 83:31.36 dovecot
1 root 15 0 1652 608 520 S 0.0 0.0 3:19.89 init
3622 root 15 0 21220 8992 5524 S 0.0 0.6 0:00.17 httpd
3651 root 19 0 2124 1040 888 S 0.0 0.1 0:00.00 mysqld_safe
3709 apache 15 0 41464 27m 4104 S 0.0 1.9 0:03.21 httpd
3728 apache 16 0 44008 29m 4276 S 0.0 2.1 0:07.59 httpd
3853 apache 16 0 44568 30m 4244 S 0.0 2.1 0:08.38 httpd
3869 apache 15 0 35084 20m 3040 S 0.0 1.4 0:01.82 httpd
9580 root 23 0 1548 576 492 S 0.0 0.0 0:00.00 udevd
9811 apache 15 0 32736 17m 2808 S 0.0 1.2 0:00.22 httpd
10042 root 15 0 1552 528 440 S 0.0 0.0 0:28.87 syslogd
10047 root 22 0 1492 372 308 S 0.0 0.0 0:00.00 klogd
10065 named 18 0 47508 2876 1920 S 0.0 0.2 0:37.05 named
10123 root 15 0 4068 1144 840 S 0.0 0.1 0:08.00 sshd
10137 root 18 0 2112 756 632 S 0.0 0.1 0:00.00 xinetd
11350 root 15 0 2632 1052 532 S 0.0 0.1 0:20.59 crond
11362 root 15 0 6404 2140 1072 S 0.0 0.1 3:11.85 dovecot-auth
11383 xfs 18 0 3172 1476 768 S 0.0 0.1 0:01.21 xfs
11401 root 16 0 1720 452 344 S 0.0 0.0 0:03.66 atd
11411 root 18 0 4092 804 576 S 0.0 0.1 0:00.00 saslauthd
11412 root 18 0 4092 468 240 S 0.0 0.0 0:00.00 saslauthd
11435 root 18 0 7344 5388 1628 S 0.0 0.4 1:41.01 miniserv.pl
11935 root 15 0 6944 2240 1804 S 0.0 0.2 0:00.01 sshd
11938 datente 15 0 7092 1520 1068 R 0.0 0.1 0:00.00 sshd
11939 datente 15 0 2176 1312 1052 S 0.0 0.1 0:00.00 bash
12005 datente 15 0 1912 992 788 R 0.0 0.1 0:00.00 top
12161 root 15 0 11164 480 336 S 0.0 0.0 0:00.00 vzctl
12162 root 17 0 2184 1292 1068 S 0.0 0.1 0:00.01 bash
13574 root 15 0 7380 2016 992 S 0.0 0.1 0:01.88 sendmail
13583 smmsp 18 0 6528 1640 828 S 0.0 0.1 0:00.00 sendmail
20230 datente 18 0 2748 1224 712 S 0.0 0.1 0:00.07 screen
20231 datente 15 0 2316 1344 1060 S 0.0 0.1 0:00.00 bash
20264 datente 26 10 1132m 2884 844 S 0.0 0.2 13:50.31 fah6
23843 dovecot 15 0 3556 1532 1268 S 0.0 0.1 4:06.58 imap-login
23845 dovecot 15 0 3552 1528 1268 S 0.0 0.1 4:07.76 imap-login
23847 dovecot 15 0 3556 1536 1272 S 0.0 0.1 4:09.06 imap-login
23899 dovecot 15 0 3556 1532 1268 S 0.0 0.1 4:07.39 imap-login
23963 dovecot 15 0 3556 1532 1268 S 0.0 0.1 4:06.99 imap-login
-
If PHP is configured properly in Apache and the client is functioning properly, the PHP script may not be specifying the proper MIME type for the content output. The
Content-typeoften has to be printed for the browser to understand how to handle the data.What is the content of the file that Firefox is attempting to download?
Chris Nava : Agree. This is a **server side** problem. Firefox is doing the best it can with bad data. The server is not setting the correct header or not executing the PHP and returning it to the client instead. looking at the contents of the file downloaded will tell you which. If it's HTML then the problem is the former if PHP then the later.warren : the issue has cleared-up over the last week, but this being a server-side issue is most reasonableFrom Warner -
Are you precompressing your page and then allowing mod_deflate to recompress? The issue you're running into is that Firefox has not received Content-length: bytes from the server, and therefore treats it as a partial download. Using live-http-headers, you'll see that it does indeed have text/html as the content type and saving the file does have the proper rendered content less a few bytes. Chunked encoding can also cause an issue if the content is just the right number of bytes.
The issue happens when Firefox encounters a short download, either via a timeout or connection closed issue (through sigkill, etc).
Warner's novice assumption that the content type is set incorrectly just shows that he's not dealt in high volume web traffic. I've noticed this behavior more frequently on 2.2.14/2.2.15 to the point that we backported a few patches to 2.2.12
Josh : Easy with the "novice assumption." Your assuming he's using mod_deflate. Your sounding a little adversarial.Warner : Seems like you're the one making the assumption. I'm recommending troubleshooting.karmawhore : As it is a serverside issue that occurs in high volume hosting, the common problem with firefox is that the content-length doesn't match what it has received from apache. This can happen for a number of reasons, one is using ob_start to compress, then mod_deflate running on top. Another is if the apache processes time out or the connection is closed before Firefox gets the last bytes of the transaction. It is not an improperly configured server as evidenced by the fact that sometimes requests work. The novice assumption is expecting different behavior from apache on each pageload.karmawhore : Why someone would assume that reloading a page repeatedly and having it work one time, and not the next, and assuming that the content-type is being set incorrectly by the server. I don't need to troubleshoot it, the issue is common, is documented in several bugs on firefox's bugtracker, and is documented in apache's bugtracker. 2.2.12 with the security patches backported fixes it. Insanity is repeating the same action over and over again, expecting different results. But, thanks again to the SF boys club for the downvotes. Do correct answers scare you guys that much?Warner : PHP could be segfaulting and then Apache is serving the request as plaintext. There's still not enough information to be sure though. One thing is certain however, mod_deflate does not impact whether or not PHP code is parsed on the server side.karmawhore : This is a well documented issue. Apache doesn't need to segfault for this to occur. The issue is that code in 2.2.14/2.2.15 changed the way connection closes are handled which Firefox doesn't like. When Firefox receives a partial download due to a number of non-tcp stack related issues, this behavior occurs. It happens in high traffic situations much more frequently. The common issues that show up are listed above. I can reiterate the points if you cannot comprehend the previous post. And you are right, mod_deflate does not interpret PHP code, kudos for getting one fact correct.Warner : If warren's results were consistently blank or had incomplete parsed results, your theory would be a good starting point. It seems that he sometimes receives raw PHP code according to his comments. It will be interesting to see what additional information he can provide.From karmawhore -
You might try loading your server (if its not production or if you have a test copy) with Apache Jarkarta Jmeter http://jakarta.apache.org/jmeter/index.html
It takes a half hour or so to figure it out if you have never used it, but it's fairly straight forward to use. You can make hundreds of requests and see the returned information from your server, and even render the pages if you desire. This may enable you to determine correlations, be it load, random, or incorrect headers\mime issues.
It's a wonderful tool that can be used for under load time diagnostics.
From Josh
0 comments:
Post a Comment