[PHP-BUG] Bug #65115 [NEW]: flush() disables compression from ob_gzhandler
From: preinheimer Operating system: linux PHP version: 5.4.16 Package: Output Control Bug Type: Bug Bug description:flush() disables compression from ob_gzhandler 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: --- https://bugs.php.net/bug.php?id=65115&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65115&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65115&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65115&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65115&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65115&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65115&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65115&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65115&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65115&r=support Expected behavior: https://bugs.php.net/fix.php?id=65115&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65115&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65115&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65115&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65115&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65115&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65115&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65115&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65115&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65115&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65115&r=mysqlcfg
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: preinhei...@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: So if I run: 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. Previous Comments: [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: --- https://bugs.php.net/bug.php?id=65115&edit=1
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: preinhei...@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: 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] m...@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] preinhei...@php.net So if I run: 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: --- https://bugs.php.net/bug.php?id=65115&edit=1
[PHP-BUG] Bug #53169 [NEW]: Segmentation Fault with parse_http_headers()
From: Operating system: Linux PHP version: 5.3.3 Package: Reproducible crash Bug Type: Bug Bug description:Segmentation Fault with parse_http_headers() Description: When running this script at the command line (php ./crash.php) I get a segmentation fault. To reproduce, save this to a script, run an instance of PHP with the pecl_http extension installed, make popcorn. Test script: --- http://www.onefortybpm.com/xmlrpc.php X-Powered-By: PHP/4.4.8 Location: http://www.onefortybpm.com/ Content-Length: 0 Connection: close Content-Type: text/html; charset=UTF-8 DATA; var_dump($data); var_dump(http_parse_headers($data)); Expected result: No seg fault Actual result: -- seg fault. -- Edit bug report at http://bugs.php.net/bug.php?id=53169&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53169&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53169&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53169&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53169&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53169&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53169&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53169&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53169&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53169&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53169&r=support Expected behavior: http://bugs.php.net/fix.php?id=53169&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53169&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53169&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53169&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53169&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53169&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53169&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53169&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53169&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53169&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53169&r=mysqlcfg
