Bug #49816 [Bgs]: output corruption using flush
Edit report at http://bugs.php.net/bug.php?id=49816edit=1 ID: 49816 User updated by:paul at wcclan dot net Reported by:paul at wcclan dot net Summary:output corruption using flush Status: Bogus Type: Bug Package:Apache2 related Operating System: * PHP Version:5.* Block user comment: N New Comment: 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? Previous Comments: [2010-08-07 13:26:52] johan...@php.net The new output buffering is in trunk, it won't be ported to 5.3. [2010-01-30 15:39:16] ben at xnode dot org 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. [2009-11-19 15:59:01] j...@php.net 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!). [2009-11-18 21:19:12] paul at wcclan dot net 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 :) [2009-11-15 00:13:20] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revisionrevision=290765 Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has working output buffering..) 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/bug.php?id=49816 -- Edit this bug report at http://bugs.php.net/bug.php?id=49816edit=1
#49816 [Asn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net Reported By: paul at wcclan dot net Status: Assigned Bug Type: Apache2 related Operating System: * PHP Version: 5.* Assigned To: jani New Comment: 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 :) Previous Comments: [2009-11-15 00:13:20] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revisionrevision=290765 Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has working output buffering..) [2009-11-14 22:28:40] j...@php.net Caused by fixing bug #49248 and does not happen with HEAD. [2009-10-26 13:05:08] j...@php.net 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(). [2009-10-25 02:28:44] magnusf at users dot sourceforge dot net 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. [2009-10-24 00:21:21] j...@php.net Apparently Apache2 is special. See bug #27424 (thanks Scott..) 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=49816edit=1
#49816 [Opn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net 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: 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. Previous Comments: [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). [2009-10-19 15:15:36] j...@php.net See also bug #48725 [2009-10-19 15:08:38] j...@php.net What was the last PHP version it worked with..? (try with same libs!) [2009-10-15 20:28:03] radek at pinkbike dot com 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(). [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. 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=49816edit=1
#49816 [Opn]: output corruption using flush
ID: 49816 User updated by: paul at wcclan dot net 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 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. Previous Comments: [2009-10-22 19:27:53] paul at wcclan dot net 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. [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). [2009-10-19 15:15:36] j...@php.net See also bug #48725 [2009-10-19 15:08:38] j...@php.net What was the last PHP version it worked with..? (try with same libs!) [2009-10-15 20:28:03] radek at pinkbike dot com 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(). 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=49816edit=1
#49816 [Opn]: output corruption using flush
ID: 49816
User updated by: paul at wcclan dot net
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:
setting zlib.output_compression to Off fixes the problem. I have no
output handlers defined. Is there anything more that might of interrest?
Previous Comments:
[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.
[2009-10-08 20:06:52] paul at wcclan dot net
Description:
Looping through the output of a process opened with popen while using
flush return garbage in the browser. Using telnet the intended output
can be seen in (likely corrupted) chuncked encoding. Commenting out the
flush() in below code fixes the problem.
Reproduce code:
---
?
$handle = popen(whois php.net, r);
if($handle)
{
while(!feof($handle))
{
$buffer = fgets($handle);
echo $buffer . br /\r\n;
flush();
}
pclose($handle);
}
?
Expected result:
the output of the command whois php.net
Actual result:
--
seemingly random garbage in browser. Above script available through:
http://ipv6.wcclan.net/test.php
--
Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49816 [NEW]: output corruption using flush
From: paul at wcclan dot net
Operating system: FreeBSD 7.2-RELEASE-p4
PHP version: 5.2.11
PHP Bug Type: Output Control
Bug description: output corruption using flush
Description:
Looping through the output of a process opened with popen while using
flush return garbage in the browser. Using telnet the intended output can
be seen in (likely corrupted) chuncked encoding. Commenting out the flush()
in below code fixes the problem.
Reproduce code:
---
?
$handle = popen(whois php.net, r);
if($handle)
{
while(!feof($handle))
{
$buffer = fgets($handle);
echo $buffer . br /\r\n;
flush();
}
pclose($handle);
}
?
Expected result:
the output of the command whois php.net
Actual result:
--
seemingly random garbage in browser. Above script available through:
http://ipv6.wcclan.net/test.php
--
Edit bug report at http://bugs.php.net/?id=49816edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49816r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49816r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49816r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49816r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49816r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49816r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49816r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49816r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49816r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49816r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49816r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49816r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49816r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49816r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49816r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49816r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49816r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49816r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49816r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49816r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49816r=mysqlcfg
#49816 [Com]: output corruption using flush
ID: 49816
Comment by: paul at wcclan dot net
Reported By: paul at wcclan dot net
Status: Feedback
Bug Type: Output Control
Operating System: FreeBSD 7.2-RELEASE-p4
PHP Version: 5.2.11
New Comment:
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.
Previous Comments:
[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.
[2009-10-08 20:06:52] paul at wcclan dot net
Description:
Looping through the output of a process opened with popen while using
flush return garbage in the browser. Using telnet the intended output
can be seen in (likely corrupted) chuncked encoding. Commenting out the
flush() in below code fixes the problem.
Reproduce code:
---
?
$handle = popen(whois php.net, r);
if($handle)
{
while(!feof($handle))
{
$buffer = fgets($handle);
echo $buffer . br /\r\n;
flush();
}
pclose($handle);
}
?
Expected result:
the output of the command whois php.net
Actual result:
--
seemingly random garbage in browser. Above script available through:
http://ipv6.wcclan.net/test.php
--
Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49816 [Fbk-Opn]: output corruption using flush
ID: 49816
User updated by: paul at wcclan dot net
Reported By: paul at wcclan dot net
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: FreeBSD 7.2-RELEASE-p4
PHP Version: 5.2.11
New Comment:
possibly interresting php.ini setting:
zlib.output_compression = On
Previous Comments:
[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.
[2009-10-08 20:06:52] paul at wcclan dot net
Description:
Looping through the output of a process opened with popen while using
flush return garbage in the browser. Using telnet the intended output
can be seen in (likely corrupted) chuncked encoding. Commenting out the
flush() in below code fixes the problem.
Reproduce code:
---
?
$handle = popen(whois php.net, r);
if($handle)
{
while(!feof($handle))
{
$buffer = fgets($handle);
echo $buffer . br /\r\n;
flush();
}
pclose($handle);
}
?
Expected result:
the output of the command whois php.net
Actual result:
--
seemingly random garbage in browser. Above script available through:
http://ipv6.wcclan.net/test.php
--
Edit this bug report at http://bugs.php.net/?id=49816edit=1
