subject:"#49816 \[Opn\-Fbk\]\: output corruption using flush"

#49816 [Opn-Fbk]: output corruption using flush

2009-10-23 Thread jani

 ID:   49816
 Updated by:   j...@php.net
 Reported By:  paul at wcclan dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: FreeBSD 7.2-RELEASE-p4
 PHP Version:  5.2.11
 New Comment:

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 :(


Previous Comments:


[2009-10-22 19:49:18] paul at wcclan dot net

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.



[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!)



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-Fbk]: output corruption using flush

2009-10-19 Thread jani

 ID:   49816
 Updated by:   j...@php.net
 Reported By:  paul at wcclan dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: FreeBSD 7.2-RELEASE-p4
 PHP Version:  5.2.11
 New Comment:

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


Previous Comments:


[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.



[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.



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-Fbk]: output corruption using flush

2009-10-08 Thread Sjoerd

 ID:   49816
 Updated by:   sjo...@php.net
 Reported By:  paul at wcclan dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: FreeBSD 7.2-RELEASE-p4
 PHP Version:  5.2.11
 New Comment:

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.


Previous Comments:


[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 [Opn-Fbk]: output corruption using flush

#49816 [Opn-Fbk]: output corruption using flush

#49816 [Opn-Fbk]: output corruption using flush

3 matches

Site Navigation

Mail list logo

Footer information