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.

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.

possibly interresting php.ini setting:
zlib.output_compression = On

setting zlib.output_compression to Off fixes the problem. I have no output handlers defined. Is there anything more that might of interrest?

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.

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 
?&#65533;&#65533;&#65533;&#65533;&#65533;&#65533;*I-.
&#65533;&#65533;&#65533;??&#65533;~?&#65533;&#65533;&#65533;

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().

What was the last PHP version it worked with..? (try with same libs!)

See also bug #48725

The last PHP version it works with is 5.2.10. Compiled in the same system (libs).

To shed some more light on this I did the following:

- In the source directory I have of my old 5.2.10 php installation I executed make install clean
- Apache restart
- The test url now displays correctly in the browser. A request through telnet shows compression is also being applied.

- In the source directory of my 5.2.11 installation I executed make install clean
- Apache restart
- The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered.

For this test I did notice something weird. With PHP 5.2.10 the response header is as follows:
HTTP/1.1 200 OK
Date: Thu, 22 Oct 2009 19:12:50 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10
X-Powered-By: PHP/5.2.10
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

With PHP 5.2.11 the response header is as follows:
HTTP/1.1 200 OK
Date: Thu, 22 Oct 2009 19:23:13 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
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush.

I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues.

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

If it fails also with this snapshot, I think I broke it when fixing bug #49248 :(

 this is reproduced with latest php 5.2 svn snapshot as well. rolling back to revision 287422 within main/SAPI.c seems to resolve this issue. 

Rolling back that is not an option. Need to figure out proper way to 
handle this.

Can not reproduce using lighttpd + PHP (FastCGI), need to test more.
Assuming this is Apache only issue for now.

Reproduced with Apache.

Apparently Apache2 is special. See bug #27424 (thanks Scott..)

Confirmed problem on Solaris 10 X86_64, PHP 5.2.11, Apache 2.2.13.
Disabling zlib output compression or reverting to 5.2.9 solves the problem. See application specific issue http://www.sugarcrm.com/forums/showthread.php?t=52694 when using 5.2.11 and flush. Problem with Apache 2.2.11 and PHP 5.2.11 so seems to be PHP issue, quote forum: "and the problem seems to rely on a change/bugfix? of the authentication/encryption mechanism in the latest 5.2.x and 5.3.x versions."

At least you can disable zlib compression in script now.. :/
See bug #49248, fix for that borked the compression on Apache if you use flush(). 

Caused by fixing bug #49248 and does not happen with HEAD.

I might be reading this wrong, but aren't you just opting not to compress with this code? If so, how do you explain that compression worked fine before 5.2.11? If I am reading it wrong, great job on the fix :)

Unfortunately flush() with apache2handler SAPI will also disable compression. Like I've said in the commit it's temporary "fix" to at least keep things working. The real fix requires doing MFH of new output buffering code where this works fine.

Johannes, please reply, I've asked you several times now whether I can merge the new and working output buffering code from HEAD (like I already suggested before 5.3.0 was released!).

Still experiencing this issue with PHP 5.3.1 and Apache 2.2.14. Quite annoying as it means either not being able to use Flush (which isn't an option for some apps) or not being able to use compression.

The new output buffering is in trunk, it won't be ported to 5.3.

with php 5.3.3 the "just don't compress" solution seems to be in place so at least it doesn't cause any problems. However, shouldn't flush() also work when applying compression?