Bug #65416 [Nab]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416&edit=1 ID: 65416 User updated by:jwestbrook at gmail dot com Reported by:jwestbrook at gmail dot com Summary:output buffering autostart setting php.ini Status: Not a bug Type: Bug Package:Output Control Operating System: linux 64bit AWS ami PHP Version:5.4.17 Block user comment: N Private report: N New Comment: I also tried the settings of On and 1. I also understand that #!/usr/bin/php means nothing to output buffering but is output that I want to capture if the php file is being run from a browser and discard. >From what I understand that is not how the output buffering works. The way I >understand it the output buffer fills then dumps everything when it is full. In this instance before the output buffer fills I want to discard the first 15 characters because it will corrupt any binary files that the browser is trying to download. Based on the test script attached ob_get_length() should ALWAYS return 15 characters - however at least 12 times a day PHP fails to start the output buffer and I get the error shown. Previous Comments: [2013-08-18 06:52:49] yohg...@php.net "#!" does not have special meaning for Web server SAPI. I think you are sending data larger than output buffer size. Then this is the way supposed to be. output_buffering=On or 1 is special. It enables unlimited buffering. Anything other values set buffer chunk size and PHP tries to send data larger than chunk size. Check your buffer size (i.e. output_buffering setting of php.ini file) I guess you have very small output_buffering. Old output buffer increases size automatically, IIRC. New output buffer does not increase buffer size. [2013-08-07 19:47:35] jwestbrook at gmail dot com Description: We recently upgraded from php 5.3 to php 5.4 and when the php.ini output_buffering setting is set to ON or anything greater than zero the output buffering does not always reliably start. This is a problem for some scripts that have a shebang as the first line to make the script easily executable. But if you send a header or anything else after that first line it will fail. based on the script attached the contents of the error log are buffer statues : Array\n(\n)\n Test script: --- #!/usr/bin/php -- Edit this bug report at https://bugs.php.net/bug.php?id=65416&edit=1
Bug #65416 [Nab]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416&edit=1 ID: 65416 User updated by:jwestbrook at gmail dot com Reported by:jwestbrook at gmail dot com Summary:output buffering autostart setting php.ini Status: Not a bug Type: Bug Package:Output Control Operating System: linux 64bit AWS ami PHP Version:5.4.17 Block user comment: N Private report: N New Comment: @mike at php.net Yes that is the bug I'm reporting - the php.ini setting does not start the output buffer on every request. Previous Comments: [2013-08-19 22:19:57] m...@php.net Looks like when this is logged, there actually is no output buffer active, so ob_get_length() returns false. [2013-08-19 22:07:01] jwestbrook at gmail dot com I also tried the settings of On and 1. I also understand that #!/usr/bin/php means nothing to output buffering but is output that I want to capture if the php file is being run from a browser and discard. >From what I understand that is not how the output buffering works. The way I >understand it the output buffer fills then dumps everything when it is full. In this instance before the output buffer fills I want to discard the first 15 characters because it will corrupt any binary files that the browser is trying to download. Based on the test script attached ob_get_length() should ALWAYS return 15 characters - however at least 12 times a day PHP fails to start the output buffer and I get the error shown. [2013-08-18 06:52:49] yohg...@php.net "#!" does not have special meaning for Web server SAPI. I think you are sending data larger than output buffer size. Then this is the way supposed to be. output_buffering=On or 1 is special. It enables unlimited buffering. Anything other values set buffer chunk size and PHP tries to send data larger than chunk size. Check your buffer size (i.e. output_buffering setting of php.ini file) I guess you have very small output_buffering. Old output buffer increases size automatically, IIRC. New output buffer does not increase buffer size. ---- [2013-08-07 19:47:35] jwestbrook at gmail dot com Description: We recently upgraded from php 5.3 to php 5.4 and when the php.ini output_buffering setting is set to ON or anything greater than zero the output buffering does not always reliably start. This is a problem for some scripts that have a shebang as the first line to make the script easily executable. But if you send a header or anything else after that first line it will fail. based on the script attached the contents of the error log are buffer statues : Array\n(\n)\n Test script: --- #!/usr/bin/php -- Edit this bug report at https://bugs.php.net/bug.php?id=65416&edit=1
Bug #65416 [Fbk->Opn]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416&edit=1 ID: 65416 User updated by:jwestbrook at gmail dot com Reported by:jwestbrook at gmail dot com Summary:output buffering autostart setting php.ini -Status: Feedback +Status: Open Type: Bug Package:Output Control Operating System: linux 64bit AWS ami PHP Version:5.4.17 Block user comment: N Private report: N New Comment: Extensions string(4) "Core" [1]=> string(4) "date" [2]=> string(4) "ereg" [3]=> string(6) "libxml" [4]=> string(7) "openssl" [5]=> string(4) "pcre" [6]=> string(4) "zlib" [7]=> string(3) "bz2" [8]=> string(8) "calendar" [9]=> string(5) "ctype" [10]=> string(4) "hash" [11]=> string(6) "filter" [12]=> string(3) "ftp" [13]=> string(7) "gettext" [14]=> string(3) "gmp" [15]=> string(3) "SPL" [16]=> string(5) "iconv" [17]=> string(10) "Reflection" [18]=> string(7) "session" [19]=> string(8) "standard" [20]=> string(5) "shmop" [21]=> string(9) "SimpleXML" [22]=> string(7) "sockets" [23]=> string(8) "mbstring" [24]=> string(9) "tokenizer" [25]=> string(3) "xml" [26]=> string(14) "apache2handler" [27]=> string(7) "gearman" [28]=> string(4) "http" [29]=> string(4) "ssh2" [30]=> string(4) "curl" [31]=> string(3) "dom" [32]=> string(8) "fileinfo" [33]=> string(2) "gd" [34]=> string(8) "igbinary" [35]=> string(4) "json" [36]=> string(4) "exif" [37]=> string(6) "mcrypt" [38]=> string(9) "memcached" [39]=> string(7) "mysqlnd" [40]=> string(5) "mysql" [41]=> string(6) "mysqli" [42]=> string(8) "newrelic" [43]=> string(3) "PDO" [44]=> string(9) "pdo_mysql" [45]=> string(10) "pdo_sqlite" [46]=> string(4) "Phar" [47]=> string(5) "posix" [48]=> string(4) "snmp" [49]=> string(4) "soap" [50]=> string(7) "sqlite3" [51]=> string(7) "sysvmsg" [52]=> string(7) "sysvsem" [53]=> string(7) "sysvshm" [54]=> string(4) "wddx" [55]=> string(9) "xmlreader" [56]=> string(9) "xmlwriter" [57]=> string(3) "xsl" [58]=> string(3) "zip" [59]=> string(5) "mhash" [60]=> string(12) "Zend OPcache" } string(14) "apache2handler" 12 requests where I was able to note that the output buffer failed out of 142 requests to that specific script. As a whole I average 150,000 PHP requests per day Previous Comments: [2013-08-26 22:45:23] yohg...@php.net I guess there is some kind of memory problem. What modules are loaded in your web server and SAPI? or paste phpinfo() output. > at least 12 times a day PHP fails to start the output buffer and I get the error shown. How many requests a day you have? [2013-08-26 21:35:48] jwestbrook at gmail dot com @mike at php.net Yes that is the bug I'm reporting - the php.ini setting does not start the output buffer on every request. [2013-08-19 22:19:57] m...@php.net Looks like when this is logged, there actually is no output buffer active, so ob_get_length() returns false. [2013-08-19 22:07:01] jwestbrook at gmail dot com I also tried the settings of On and 1. I also understand that #!/usr/bin/php means nothing to output buffering but is output that I want to capture if the php file is being run from a browser and discard. >From what I understand that is not how the output buffering works. The way I >understand it the output buffer fills then dumps everything when it is full. In this instance before the output buffer fills I want to discard the first 15 characters because it will corrupt any binary files that the browser is trying to download. Based on the test script attached ob_get_length() should ALWAYS return 15 characters - however at least 12 times a day PHP fails t
[PHP-BUG] Bug #65416 [NEW]: output buffering autostart setting php.ini
From: jwestbrook at gmail dot com Operating system: linux 64bit AWS ami PHP version: 5.4.17 Package: Output Control Bug Type: Bug Bug description:output buffering autostart setting php.ini Description: We recently upgraded from php 5.3 to php 5.4 and when the php.ini output_buffering setting is set to ON or anything greater than zero the output buffering does not always reliably start. This is a problem for some scripts that have a shebang as the first line to make the script easily executable. But if you send a header or anything else after that first line it will fail. based on the script attached the contents of the error log are buffer statues : Array\n(\n)\n Test script: --- #!/usr/bin/php -- Edit bug report at https://bugs.php.net/bug.php?id=65416&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65416&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65416&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65416&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65416&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65416&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65416&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65416&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65416&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65416&r=support Expected behavior: https://bugs.php.net/fix.php?id=65416&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65416&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65416&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65416&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65416&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65416&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65416&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65416&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65416&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65416&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65416&r=mysqlcfg
