|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2022-04-08 08:17 UTC] ilutov@php.net
-Status: Open
+Status: Closed
-Package: Feature/Change Request
+Package: *General Issues
-Assigned To:
+Assigned To: ilutov
[2022-04-08 08:17 UTC] ilutov@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Oct 25 07:00:02 2025 UTC |
Description: ------------ Opening the "php://stderr" stream and writing to it in FastCGI mode writes to the FCGI server's standard error, not the multiplexed request standard error stream. Reproduce code: --------------- $stderr = fopen("php://stderr", "w"); fputs($stderr, "fish soup is good for you"); Expected result: ---------------- This should log an error message to the server's error log when the script is running in a web server environment. (Note that error_log can't necessarily be used in this context, because it always appends a "\n" to anything you send, and is also affected by the configuration file.) Actual result: -------------- Under FastCGI mode, it doesn't log such a message, but instead writes it to the FGGI *server's* standard error stream, which isn't the same thing at all. The message should be written via the multiplexed FastCGI error stream, not to fd #2. (See also a related bug, http://bugs.php.net/bug.php?id=28074 , which I've fixed.) Basically this is simple but a bit messy to fix. In ext/standard/php_fopen_wrapper.c the php://stderr case (and possibly the other ones) need to be treated specially in the FastCGI case, defining new stream output operations for the FastCGI streams.