php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65416 output buffering autostart setting php.ini
Submitted: 2013-08-07 19:47 UTC Modified: 2013-10-15 18:25 UTC
From: jwestbrook at gmail dot com Assigned:
Status: Not a bug Package: Output Control
PHP Version: 5.4.17 OS: linux 64bit AWS ami
Private report: No CVE-ID: None
 [2013-08-07 19:47 UTC] 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
<?php

$buffer_length = ob_get_length();
if($buffer_length != 15)
{
    error_log('buffer statues : '.print_r(ob_get_status(TRUE),1));
    exit;
}

//this header call will not always be successful
header("Content-type: application/pdf");

?>


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-08-18 06:52 UTC] yohgaki@php.net
-Status: Open +Status: Not a bug
 [2013-08-18 06:52 UTC] yohgaki@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-19 22:07 UTC] 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-19 22:19 UTC] mike@php.net
Looks like when this is logged, there actually is no output buffer active, so 
ob_get_length() returns false.
 [2013-08-26 21:35 UTC] 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-26 22:45 UTC] yohgaki@php.net
-Status: Not a bug +Status: Feedback
 [2013-08-26 22:45 UTC] yohgaki@php.net
I guess there is some kind of memory problem.
What modules are loaded in your web server and SAPI?

<?php
var_dump(get_loaded_extensions(), php_sapi_name());                                                               
?>

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-27 00:42 UTC] jwestbrook at gmail dot com
-Status: Feedback +Status: Open
 [2013-08-27 00:42 UTC] jwestbrook at gmail dot com
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
 [2013-09-26 14:30 UTC] mike@php.net
-Status: Open +Status: Feedback
 [2013-09-26 14:30 UTC] mike@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.



 [2013-10-15 11:54 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2013-10-15 18:08 UTC] jwestbrook at gmail dot com
-Status: No Feedback +Status: Closed
 [2013-10-15 18:08 UTC] jwestbrook at gmail dot com
This was resolved when the php agent from New Relic was updated the end of August.
 [2013-10-15 18:25 UTC] mike@php.net
-Status: Closed +Status: Not a bug
 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Feb 05 18:03:43 2023 UTC