PHP upgrade problem - Is this an encoding error?

I upgraded php-common and php-devel packages on CentOS 5.3 system. Now, when I try to access any PHP script in a browser I get garbage like this:

alt text http://javierdesign.com/error.jpg

If I try to CURL GET the page, or try plain HTML, CSS or JS in the browser everything looks OK.

Encoding is set to UTF-8 in both PHP itself and the PHP output via "Content-Type: text/html; charset=UTF-8".

I am lost as to what may have caused the change? Any ideas??

13.10.2009 15:20:50
Have you tried if phpinfo() is working?
michal kralik 13.10.2009 15:22:30
yep, a simple phpinfo() outputs everything OK
Miro Solanka 13.10.2009 15:25:18
Can you include the first few characters? I'm guessing it's gzip content but can't tell without seeing the start
Greg 13.10.2009 15:26:31
2 ОТВЕТА
РЕШЕНИЕ

We had this once. I believe this has something to do with gzip.

try to modify the zlib.output_compression from the original value Off to On

2
13.10.2009 15:45:11
Apache 2 and yes gzip is enabled, though I believe in my 3 hours of trying to fix this today, I tried to disable DEFLATE to no avail...
Miro Solanka 13.10.2009 15:26:19
Hmm, - one thing I did not try previously was to change zlib.output_compression from the original value Off to On which fixed the problem. Yeeha! You may want to add this to your answer, as I can't edit other posts, then I can mark it accepted. Thanks for the tip.
Miro Solanka 13.10.2009 15:31:14

Wow. Yea, that's unusual. My first thought was that the MOD_PHP bit in Apache must have gotten screwed up somehow (or the equivalent in whatever webserver you're using), or that it was binding to the wrong MIME type, or something...But since php isn't (minus an interpreter) compiled code, if it was truly fubared, you'd just be seeing plain text, or nothing at all, not binary gibberish. Looks more like the server is handling .php as some kind of binary file type.

I'd clear out the packages and install them again. Was the original install from "stock" packages, or did someone compile them from source? If they were compiled the first time, someone may have set options that were not set in the official packages, which might be causing your issue.

It could be some kind of encoding issue, but since you just upgraded those packages, that would be the place where I would start.

1
13.10.2009 15:32:05
followed your reasoning with the MIME types, though it seems to me now that the Request header "Accept-encoding: gzip, deflate;" tricked PHP into gzipping the content which was then deflated by Apache again, which would not happen with CURL...
Miro Solanka 13.10.2009 15:41:27