From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: httpd-2.0.48-1.2 php-4.3.4-1.1 vbulletin software used, gzip enabled Happens when apache is reloaded Gzip compression turns itself always on when it's supposed to only be on on browsers that suppport it. What happens is when you request the site, even using wget from the command line, it sends the output in gzip format which obviously it saves index.html as a bunch of garbage. Under normal circumstances this wouldn't happen. If we restart the httpd server it fixes the problem. If we reload the httpd server the problem comes back. It seems to fix it we have to stop the server (and wait until all the processes are stopped), then start it. Now for browsers that support gzip all the way the clients don't notice it on the site, but for those who don't and those who are using proxy servers they can't view the site at all unless the 'bug' is fixed by the restart. We also noticed that sometimes a reload of httpd will cause the server to stop working but on rare occasions. Version-Release number of selected component (if applicable): httpd-2.0.48-1.2 How reproducible: Sometimes Steps to Reproduce: 1. reload apache 2. request url with gzip enabled and see output (wget) 3. restart apache 4. request url with gzip enabled and see output (wget) Actual Results: wget -d -s http://www.hostraiders.com DEBUG output created by Wget 1.8.2 on linux-gnu. --11:10:10-- http://www.hostraiders.com/ => `index.html' Resolving www.hostraiders.com... done. Caching www.hostraiders.com => 66.225.226.42 Connecting to www.hostraiders.com[66.225.226.42]:80... connected. Created socket 3. Releasing 0x8918528 (new refcount 1). ---request begin--- GET / HTTP/1.0 User-Agent: Wget/1.8.2 Host: www.hostraiders.com Accept: */* Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Fri, 23 Apr 2004 16:08:15 GMT Server: Apache/2.0.48 (Fedora) Accept-Ranges: bytes Connection: close Content-Type: text/html; charset=ISO-8859-1 Length: unspecified [text/html] [ <=> ] 21,872 20.86M/s Closing fd 3 11:10:10 (20.86 MB/s) - `index.html' saved [21872] this is how it should look.. and index.html is in HTML format when the bug happens, it says GZIP in the header and the index.html is garbage .. Expected Results: I can't reproduce it right now because it's a production server but next time it comes up I will (if i can) add to this post. Additional info:
Can you attach your httpd.conf and any changed conf.d/*.conf files? Once it gets into this bad state, you say httpd serving *all* requests using Content-Encoding: gzip, regardless of Accept-Encoding, or is it just all requests to a specific URI? It would be most useful if you can add a new log file (or extend an existing log file) and log the "Accept-Encoding" request header and the "Content-Encoding" response header, to help track this down; something like: LogFormat "%h %l %u %t \"%r\" \"%{Accept-Encoding}i\" \"%{Content-Encoding}o\" \"%{User-Agent}i\"" encodings CustomLog logs/encoding_log encodings (with the LogFormat all on one line, if it's wrapped by bugzilla)
Created attachment 99654 [details] http.conf for bug
htmlforums.com is the only web site that has gzip enabled content by vbulletin as far as I know. Only requests to that site are served all in gzip, the other sites on the same daemon are fine. Is there a way to privately attach configs? The configs in conf.d are all default except the ssl one where I disabled ssl. I'll attach the httpd.conf with some of the stuff removed.. and i'll try reloading the server now with the new log and see if the gzip problem shows up and post the results
sorry i originally posted the wrong web site for the wget, but that's what a normal wget looks like and right now i can't give you the 'wrong' wget header from htmlforums although next time the server reloads i'll be sure to post it.. i'm trying to reload it now with the encoding log
Woah, hang on: are you talking about using PHP to gzip the content, or doing it using mod_deflate?
OK! It did it! we reloaded it, AND i think i found another problem.. this is the output from WGET wget -d -s http://www.htmlforums.com DEBUG output created by Wget 1.8.2 on linux-gnu. --12:52:53-- http://www.htmlforums.com/ => `index.html.3' Resolving www.htmlforums.com... done. Caching www.htmlforums.com => 66.225.226.42 Connecting to www.htmlforums.com[66.225.226.42]:80... connected. Created socket 3. Releasing 0x8a7f528 (new refcount 1). ---request begin--- GET / HTTP/1.0 User-Agent: Wget/1.8.2 Host: www.htmlforums.com Accept: */* Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Fri, 23 Apr 2004 17:50:41 GMT Server: Apache/2.0.48 (Fedora) X-Powered-By: PHP/4.3.4 Set-Cookie: sessionhash=c698806cf3df6128956fae4acca66f21; path=/ Stored cookie www.htmlforums.com 80 / nonpermanent 0 Wed Dec 31 17:59:59 1969 sessionhash c698806cf3df6128956fae4acca66f21 Set-Cookie: bblastvisit=1082742641; expires=Sat, 23-Apr-2005 17:50:41 GMT; path=/ Stored cookie www.htmlforums.com 80 / permanent 0 Sat Apr 23 12:50:41 2005 bblastvisit 1082742641 Content-Encoding: gzip Content-Length: 11192 Connection: close Content-Type: text/html; charset=ISO-8859-1 Length: 11,192 [text/html] 100%[===========================================================================>] 11,192 10.67M/s ETA 00:00 Closing fd 3 12:52:53 (10.67 MB/s) - `index.html.3' saved [11192/11192] And now, i issued httpd restart wget -d -s http://www.htmlforums.com DEBUG output created by Wget 1.8.2 on linux-gnu. --12:55:19-- http://www.htmlforums.com/ => `index.html.5' Resolving www.htmlforums.com... done. Caching www.htmlforums.com => 66.225.226.42 Connecting to www.htmlforums.com[66.225.226.42]:80... connected. Created socket 3. Releasing 0x97b6528 (new refcount 1). ---request begin--- GET / HTTP/1.0 User-Agent: Wget/1.8.2 Host: www.htmlforums.com Accept: */* Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Fri, 23 Apr 2004 17:53:07 GMT Server: Apache/2.0.48 (Fedora) X-Powered-By: PHP/4.3.4 Set-Cookie: sessionhash=c698806cf3df6128956fae4acca66f21; path=/ Stored cookie www.htmlforums.com 80 / nonpermanent 0 Wed Dec 31 17:59:59 1969 sessionhash c698806cf3df6128956fae4acca66f21 Set-Cookie: bblastvisit=1082742787; expires=Sat, 23-Apr-2005 17:53:07 GMT; path=/ Stored cookie www.htmlforums.com 80 / permanent 0 Sat Apr 23 12:53:07 2005 bblastvisit 1082742787 Content-Length: 64730 Connection: close Content-Type: text/html; charset=ISO-8859-1 Length: 64,730 [text/html] 100%[===========================================================================>] 64,730 7.72M/s ETA 00:00 Closing fd 3 12:55:19 (7.72 MB/s) - `index.html.5' saved [64730/64730] and the encoding LOG these are the two requests i made where wget downaloded the gzip garbage 66.225.226.200 - - [23/Apr/2004:12:50:26 -0500] "GET / HTTP/1.0" "-" "gzip" "Wget/1.8.2" 66.225.226.200 - - [23/Apr/2004:12:50:41 -0500] "GET / HTTP/1.0" "-" "gzip" "Wget/1.8.2" and these are the normal ones i did after restart 66.225.226.200 - - [23/Apr/2004:12:52:23 -0500] "GET / HTTP/1.0" "-" "-" "Wget/1.8.2" 66.225.226.200 - - [23/Apr/2004:12:53:07 -0500] "GET / HTTP/1.0" "-" "-" "Wget/1.8.2" The kicker is.... It only seems to happen either when logrorate kills the server , OR when the server is restarted in WEBMIN by hitting apply changes.. i tried to use the command line (the redhat service httpd reload and service httpd restart) and it doesn't show the bug then..
PHP does the gzipping.. mod_deflate i don't even think is loaded the problem is apache sends the acceptable encoding of gzip or it reads it even though it's not there.. as you can see in the encoding log
There's nothing obviously wrong with how php determines whether to gzip. In case this is related to the config setting leaking bug, can you try the packages from here: http://people.redhat.com/jorton/FedoraC1-php/
Are these safe to try on a production server? Also, why would it only happen if logrotate and webmin restart apache and not doing it from the command script? Something is odd..
Yes, safe to try on a production server.
*** Bug 121589 has been marked as a duplicate of this bug. ***
Moving to NEEDINFO pending testing of update php packages.
[This is a mass bug update] Fedora Core 1 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 or FC4 updates, reopen and change the version to match.