|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #65115 flush() disables compression from ob_gzhandler
Submitted: 2013-06-24 21:08 UTC Modified: 2024-01-25 13:36 UTC
From: Assigned: girgias (profile)
Status: Closed Package: Output Control
PHP Version: 5.4.16 OS: linux
Private report: No CVE-ID: None
 [2013-06-24 21:08 UTC]

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:

Expected result:
output compressed

Actual result:
no compression


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-25 04:32 UTC]
I encountered this problem too.

a workaround is don't use php's gzip handler, use the webserver's
 [2013-06-25 04:37 UTC]
-Assigned To: +Assigned To: mike
 [2013-06-25 05:30 UTC]
-Status: Assigned +Status: Not a bug
 [2013-06-25 05:30 UTC]
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 
 [2013-06-25 12:33 UTC]
So if I run:


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 13:49 UTC]
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 13:56 UTC]
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'
 [2013-06-25 14:05 UTC]
Ok, my explanation pretty much applies to the Apache SAPI.

Due to premature flush()'ing the ob_gzhandler cannot set its headers anymore when it's actually run.
 [2013-06-25 15:40 UTC]
-Status: Not a bug +Status: Open -Type: Bug +Type: Documentation Problem -Assigned To: mike +Assigned To:
 [2013-06-25 15:40 UTC]
flush() causes Apache2 to send it's headers, so the gzhandler cannot send any headers and does nothing any more
 [2013-06-25 15:41 UTC]
-Assigned To: +Assigned To: preinheimer
 [2016-09-28 14:39 UTC]
I've just had a look at your submitted patch (, Paul.
It seems that it's not complete, because the man page would still

| also doesn't affect PHP's userspace output buffering mechanism.
| This means you will have to call both ob_flush() and flush() to
| flush the ob output buffers if you are using those.

According to what has been said in this ticket this info is wrong.
 [2017-10-24 06:21 UTC]
-Status: Assigned +Status: Analyzed -Assigned To: preinheimer +Assigned To:
 [2024-01-25 13:36 UTC]
-Status: Analyzed +Status: Closed -Assigned To: +Assigned To: girgias
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 23 01:01:29 2024 UTC