php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47397 php://stdout gives odd behavior under CGI/Apache
Submitted: 2009-02-15 19:16 UTC Modified: 2009-02-23 01:00 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: shaunspiller at gmail dot com Assigned:
Status: No Feedback Package: Output Control
PHP Version: 5.2.9RC2 OS: Any?
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: shaunspiller at gmail dot com
New email:
PHP Version: OS:

 

 [2009-02-15 19:16 UTC] shaunspiller at gmail dot com
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.





Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-02-15 23:15 UTC] jani@php.net
1. Exactly what PHP version are you using here?
2. What if you don't open another stdout stream but use the STDOUT 
constant, does it work better..?

For more info: http://www.php.net/wrappers.php

 [2009-02-16 16:12 UTC] shaunspiller at gmail dot com
I'm using "php-5.2.9RC2-Win32-VC6-x86.zip" (last modified: 2009-Feb-12).

The STDOUT constant is only defined for CLI. The documentation isn't clear on what the correct behavior of the stdout stream should be under other interfaces.
 [2009-02-23 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-11-27 11:47 UTC] ruj dot sabya at gmail dot com
I am also facing this problem.
Version: 5.2.9-2
 [2012-11-06 22:25 UTC] jasen at treshna dot com
Jani linked to the answer in comment 1

the CGI, CLI, and apache module environments 
all have different standard definitions of STDOUT

These standards are outside of the control of PHP 

If you want stdout use stdout, If you want fwrite to work like echo 
use "php://output" instead.

If you found documentation unclear or incomplete you could rause a bug against thwe documentatuion.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 20:01:28 2024 UTC