Bug #65115 [Com]: flush() disables compression from ob_gzhandler
Edit report at https://bugs.php.net/bug.php?id=65115&edit=1
ID: 65115
Comment by: preinheimer@php.net
Reported by: preinheimer@php.net
Summary: flush() disables compression from ob_gzhandler
Status: Not a bug
Type: Bug
Package: Output Control
Operating System: linux
PHP Version: 5.4.16
Assigned To: mike
Block user comment: N
Private report: N
New Comment:
I'm using the apache 2.0 SAPI.
The build of PHP I used to confirm the bug doesn't include XHProf (I wanted a clean build to
report on).
I built with:
Command './configure' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-mysql=mysqlnd' '--with-gd' '--enable-soap'
'--with-libxml-dir=/usr/lib/' '--with-mysql-sock=/tmp' '--with-tidy'
'--with-jpeg-dir=/usr/lib/' '--with-xsl' '--with-curl'
'--with-zlib' '--enable-gd-native-ttf' '--with-openssl'
'--with-mcrypt' '--with-pdo-mysql=mysqlnd' '--with-mysqli=mysqlnd'
'--with-bz2' '--enable-bcmath'
Previous Comments:
------------------------------------------------------------------------
[2013-06-25 13:49:38] mike@php.net
Looks like my explanation off the top of my head was not correct.
Which SAPI are you using? Does XHPROF override SAPI methods?
------------------------------------------------------------------------
[2013-06-25 12:33:48] preinheimer@php.net
So if I run:
<?php
ob_start('ob_gzhandler');
phpinfo();
ob_flush();
phpinfo();
flush();
With something like:
curl -H "Accept-Encoding: gzip, deflate" http://test.local/obtest.php
It looks (to me) like the entire output is compressed. The difference in behavior seems, well,
necessary to allow the end agent to actually be able to read the output. But confusing from a
"different output depending on what happened earlier" standpoint.
------------------------------------------------------------------------
[2013-06-25 05:30:36] mike@php.net
Actually, this is debatable. Flush
flushes the SAPI's I/O layer and we
just note that output has
irreversibly sent. If you want to
flush the output buffering layer
you have to use ob_flush prior
flush.
------------------------------------------------------------------------
[2013-06-25 04:32:20] laruence@php.net
I encountered this problem too.
a workaround is don't use php's gzip handler, use the webserver's
------------------------------------------------------------------------
[2013-06-24 21:08:07] preinheimer@php.net
Description:
------------
Hi,
Consider the test script.
One might expect to see: Content-Encoding: gzip in the response headers, but it's not there. If
however you comment out that flush() compression is applied.
As a small amount of background, I work on two tools that help display data from the xhprof
extension. They both include flush(); ignore_user_abort(); before doing work to store the profiling
information in attempt to have as little impact on the user as possible. Clearly flush() wasn't
the safe command I thought it was, as it's having a large affect on the application I'm
profiling.
I'm prepared to write this up in the documentation, but I don't really think this is
expected behavior.
Test script:
---------------
<?php
ob_start('ob_gzhandler');
phpinfo();
flush();
Expected result:
----------------
output compressed
Actual result:
--------------
no compression
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=65115&edit=1
Thread (7 messages)