Edit report at https://bugs.php.net/bug.php?id=65115&edit=1
ID: 65115
Updated by: m...@php.net
Reported by: preinhei...@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:
Looks like my explanation off the top of my head was not correct.
Which SAPI are you using? Does XHPROF override SAPI methods?
Previous Comments:
------------------------------------------------------------------------
[2013-06-25 12:33:48] preinhei...@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] m...@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] larue...@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] preinhei...@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
