ID: 49816
Comment by: radek at pinkbike dot com
Reported By: paul at wcclan dot net
Status: Open
Bug Type: Output Control
Operating System: FreeBSD 7.2-RELEASE-p4
PHP Version: 5.2.11
New Comment:
I have the same problem on Centos 5.2, php 5.2.11
Encoding bug using flush with zlib output handler.
To reproduce...
Turn on zlib.output_compression = On
and load a page containing the following with a browser.
<?
echo "test";
flush();
?>
the result is garbled up
������*I-.���ÿÿ�
~���
If you dont use flush() works correctly.
If you dont turn on zlib.output_compression works correctly.
Note that it's not simply user config error as it works correctly
without flush().
Previous Comments:
------------------------------------------------------------------------
[2009-10-10 16:57:40] alec at alec dot pl
Same here on Gentoo. Nothing was changed in configuration only PHP has
been updated to 5.2.11 and my scripts stops working.
zlib.output_compression=Off fixes issue, but also disables compression.
Maybe important, I've got updated zlib library to version 1.2.3 in the
same time.
------------------------------------------------------------------------
[2009-10-09 17:07:47] paul at wcclan dot net
setting zlib.output_compression to Off fixes the problem. I have no
output handlers defined. Is there anything more that might of interrest?
------------------------------------------------------------------------
[2009-10-08 21:12:05] paul at wcclan dot net
possibly interresting php.ini setting:
zlib.output_compression = On
------------------------------------------------------------------------
[2009-10-08 21:05:50] paul at wcclan dot net
Thanks for the response. As far as I know I didn't make any changes to
the compression settings. Anything specific I should look at? The
request and headers are as follows:
GET /ipinfo HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg,
application/x-ms-application, application/vnd.ms-xpsdocument,
application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: nl
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64;
x64; Trident/4.0; .NET CLR 2.0.50727; SLCC1; .NET CLR 3.5.30729; .NET
CLR 3.0.30729)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: ipv6.wcclan.net
Connection: Keep-Alive
With flush in code (broken output):
HTTP/1.1 200 OK
Date: Thu, 08 Oct 2009 20:58:50 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11
X-Powered-By: PHP/5.2.11
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 664
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Without flush in code (correct output):
HTTP/1.1 200 OK
Date: Thu, 08 Oct 2009 20:59:19 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11
X-Powered-By: PHP/5.2.11
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 750
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Your hint about compression is correct. Both the requests are handled
with compression. The code using flush returns "garbage" the code not
using flush returns correct output.
------------------------------------------------------------------------
[2009-10-08 20:44:01] sjo...@php.net
Thank you for bug report.
The garbage data you see in the browser is the correct page, but
compressed. The data is probably automatically compressed by Apache or
PHP, without setting the correct headers. Because the headers are not
set, the browser does not uncompress the page.
Please check your server settings and confirm this is the problem.
There may still be a bug here, in that flush() breaks gzip compression.
In that case we need some more information on how the compression is
configured.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49816
--
Edit this bug report at http://bugs.php.net/?id=49816&edit=1
