Bug 121588 - apache gzip compression problems on reload
apache gzip compression problems on reload
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
: 121589 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-23 12:05 EDT by Paul
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-21 11:47:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
http.conf for bug (14.74 KB, text/plain)
2004-04-23 13:33 EDT, Paul
no flags Details

  None (edit)
Description Paul 2004-04-23 12:05:06 EDT
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:
Comment 1 Joe Orton 2004-04-23 12:32:33 EDT
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)

Comment 2 Paul 2004-04-23 13:33:31 EDT
Created attachment 99654 [details]
http.conf for bug
Comment 3 Paul 2004-04-23 13:34:02 EDT
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
Comment 4 Paul 2004-04-23 13:41:13 EDT
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 
Comment 5 Joe Orton 2004-04-23 13:43:49 EDT
Woah, hang on: are you talking about using PHP to gzip the content, or
doing it using mod_deflate?
Comment 6 Paul 2004-04-23 13:49:45 EDT
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..
Comment 7 Paul 2004-04-23 13:51:35 EDT
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
Comment 8 Joe Orton 2004-04-23 15:16:20 EDT
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/
Comment 9 Paul 2004-04-23 20:02:25 EDT
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.. 
Comment 10 Joe Orton 2004-04-29 07:17:25 EDT
Yes, safe to try on a production server.
Comment 11 Joe Orton 2004-04-29 07:18:47 EDT
*** Bug 121589 has been marked as a duplicate of this bug. ***
Comment 12 Joe Orton 2004-04-30 08:05:56 EDT
Moving to NEEDINFO pending testing of update php packages.
Comment 13 Joe Orton 2005-06-21 11:47:26 EDT
[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.

Note You need to log in before you can comment on or make changes to this bug.