From: shaunspiller at gmail dot com
Operating system: Any?
PHP version: 5.2.9RC2
PHP Bug Type: *General Issues
Bug description: php://stdout gives odd behavior under CGI/Apache
Description:
------------
Hi!
I think this might be a bug. I was writing some code that used output
buffering, but which also bypassed it by writing directly to stdout. I've
done before it under CLI but the results I got under CGI and as an Apache
module were a bit strange:
Example 1:
----------
<?php
echo "1. echo, before output buffering<br>\n";
ob_start();
echo "2. echo, during output buffering<br>\n";
flush();
/* in theory, this line will be output immediately while 2 & 4 will be
held back until ob_end_flush() */
$stdout = fopen('php://stdout', 'w');
fwrite($stdout, "3. fwrite to stdout, during output buffering<br>\n");
echo "4. echo, during output buffering<br>\n";
ob_end_flush();
echo "5. echo, after output buffering<br>\n";
?>
Result:
-------
I'm not expert on how PHP communicates with its various output mechanisms.
These are just my observations from testing this code:
* Under CLI, this example works, and the displayed order is 1, 3, 2, 4,
5.
* As an Apache module, no. 3 is never output, no matter how much I try to
flush it through. (Maybe that is the intended behavior, since the STDOUT
constant is not defined.)
* Under CGI, no. 3 is never output.... **unless** at least 1 previous byte
has been flushed (provided by the echo()s and flush() call, above). In that
case, the displayed order is 1, 3, 2, 4, 5 again. I'm not sure if it's
supposed to work or not, but the inconsistency seems wrong.
* (In all cases, the fopen call returns a valid stream.)
Example 2:
----------
<?php
header('Cache-Control: no-cache');
$stdout = fopen('php://stdout', 'w');
fwrite($stdout, "Location: http://www.php.net/\r\n";);
?>
Result:
-------
This is even stranger. Under CGI, if at least one call to header() has
been made and no other data has yet been flushed, writing to stdout puts
data directly into the HTTP response. In this case I've used a complete
valid header so it can be tested from a browser.
It's also possible to write complete garbage into the headers, bypassing
the header() function's restrictions (this is best observed via telnet),
and this is what was unintentionally happening when I first encountered
this.
Expected result:
----------------
It would be nice if stdout would always work, and always bypass output
buffering. Otherwise, it should at least be consistent within each
interface.
--
Edit bug report at http://bugs.php.net/?id=47397&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47397&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47397&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47397&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47397&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47397&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47397&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47397&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47397&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47397&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47397&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47397&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47397&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47397&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47397&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47397&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=47397&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47397&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47397&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47397&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47397&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47397&r=mysqlcfg
