# #28074 [Opn->Asn]: Fast CGI standard compliance : stderr should be written in a FCGI stderr stream (fwd)

- Thread: https://externals.io/message/16123
- Original archive: https://news-web.php.net/php.internals/16123
- Started by Sascha Schumann on 2005-04-28T12:29:43+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #16123 — Sascha Schumann — 2005-04-28T12:29:43+00:00

URL: https://externals.io/message/16123#16123

I'm more of the mindset that whoever breaks it, also fixes
     it.

     My current 'fix' would simply revert that patch.  If you
     agree with that, I will happily follow through.

     - Sascha

---------- Forwarded message ----------
Date: Thu, 28 Apr 2005 12:58:05 +0200
From: sniper@php.net
To: sas@php.net
Subject: #28074 [Opn->Asn]: Fast CGI standard compliance : stderr should be
     written in a FCGI stderr stream

sas@php.net you have just been assigned to this bug by sniper@php.net

  ID:               28074
  Updated by:       sniper@php.net
  Reported By:      bogus_idp at yahoo dot fr
-Status:           Open
+Status:           Assigned
  Bug Type:         CGI related
  Operating System: *
  PHP Version:      4CVS, 5CVS (2005-01-10)
-Assigned To:
+Assigned To:      sas
  New Comment:

Feel free to fix it then.



Previous Comments:
------------------------------------------------------------------------

[2005-04-21 11:43:51] sas@php.net

This is an ugly change for users who redirect PHP's stderr to a log
file due to file permissions (PHP is not allowed to open the log
file).

Instead of writing to the log file, the Apache log now contains tons of
rows like this:

[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server "/home/www/PHP/php/bin/php" stderr: array (
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server "/home/www/PHP/php/bin/php" stderr:   'rcs' =>
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server "/home/www/PHP/php/bin/php" stderr:   array (

etc.

This needs to be addressed -- make logging to fastcgi's stderr
optional.


------------------------------------------------------------------------

[2005-01-10 16:01:29] chris at ex-parrot dot com

This one turns out to be easy to fix, thus:

--- cgi_main.c.orig     Mon Jan 10 14:57:04 2005
+++ cgi_main.c  Mon Jan 10 14:53:44 2005
@@ -481,7 +481,14 @@

  static void sapi_cgi_log_message(char *message)
  {
-       fprintf(stderr, "%s\n", message);
+#if PHP_FASTCGI
+    if (!FCGX_IsCGI()) {
+        FCGX_Request *request = (FCGX_Request *)SG(server_context);
+        FCGX_FPrintF( request->err, "%s\n", message );
+            /* ignore return code */
+    } else
+#endif /* PHP_FASTCGI */
+           fprintf(stderr, "%s\n", message);
  }

  static int sapi_cgi_deactivate(TSRMLS_D)


However, there is another similar bug, which is that a stream opened on
"php://stderr" should also direct its output to the FCGI error stream
(rather than just to file descriptor #2).

-- Chris Lightfoot

------------------------------------------------------------------------

[2004-04-20 12:03:30] bogus_idp at yahoo dot fr

Description:
------------
The Fast CGI standard require that error be reported through the
FastCGI connection as a Stderr data stream.
But PHP Fast CGI processes still write errors to original stderr (file
handle 3) which prevent from clean standard centralized FCGI logging,
especially when the Fast CGI PHP process is not started by the web
server (remote Fast CGI).

In most cases, it makes debugging PHP scripts impossible.



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=28074&edit=1

---

## #16124 — Jani Taskinen — 2005-04-28T13:15:06+00:00

URL: https://externals.io/message/16123#16124 · In reply to: #16123

I addded fastcgi.logging ini option. Set that to 0 and you'll
     get the original behaviour back.

     --Jani




>    I'm more of the mindset that whoever breaks it, also fixes
>    it.
>
>    My current 'fix' would simply revert that patch.  If you
>    agree with that, I will happily follow through.
>
>    - Sascha
>
> ---------- Forwarded message ----------
> Date: Thu, 28 Apr 2005 12:58:05 +0200
> From: sniper@php.net
> To: sas@php.net
> Subject: #28074 [Opn->Asn]: Fast CGI standard compliance : stderr should be
>    written in a FCGI stderr stream
>
> sas@php.net you have just been assigned to this bug by sniper@php.net
>
> ID:               28074
> Updated by:       sniper@php.net
> Reported By:      bogus_idp at yahoo dot fr
> -Status:           Open
> +Status:           Assigned
> Bug Type:         CGI related
> Operating System: *
> PHP Version:      4CVS, 5CVS (2005-01-10)
> -Assigned To:
> +Assigned To:      sas
> New Comment:
>
> Feel free to fix it then.
>
>
>
> Previous Comments:
> ------------------------------------------------------------------------
>
> [2005-04-21 11:43:51] sas@php.net
>
> This is an ugly change for users who redirect PHP's stderr to a log
> file due to file permissions (PHP is not allowed to open the log
> file).
>
> Instead of writing to the log file, the Apache log now contains tons of
> rows like this:
>
> [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
> server "/home/www/PHP/php/bin/php" stderr: array (
> [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
> server "/home/www/PHP/php/bin/php" stderr:   'rcs' =>
> [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
> server "/home/www/PHP/php/bin/php" stderr:   array (
>
> etc.
>
> This needs to be addressed -- make logging to fastcgi's stderr
> optional.
>
>
> ------------------------------------------------------------------------
>
> [2005-01-10 16:01:29] chris at ex-parrot dot com
>
> This one turns out to be easy to fix, thus:
>
> --- cgi_main.c.orig     Mon Jan 10 14:57:04 2005
> +++ cgi_main.c  Mon Jan 10 14:53:44 2005
> @@ -481,7 +481,14 @@
>
> static void sapi_cgi_log_message(char *message)
> {
> -       fprintf(stderr, "%s\n", message);
> +#if PHP_FASTCGI
> +    if (!FCGX_IsCGI()) {
> +        FCGX_Request *request = (FCGX_Request *)SG(server_context);
> +        FCGX_FPrintF( request->err, "%s\n", message );
> +            /* ignore return code */
> +    } else
> +#endif /* PHP_FASTCGI */
> +           fprintf(stderr, "%s\n", message);
> }
>
> static int sapi_cgi_deactivate(TSRMLS_D)
>
>
> However, there is another similar bug, which is that a stream opened on
> "php://stderr" should also direct its output to the FCGI error stream
> (rather than just to file descriptor #2).
>
> -- Chris Lightfoot
>
> ------------------------------------------------------------------------
>
> [2004-04-20 12:03:30] bogus_idp at yahoo dot fr
>
> Description:
> ------------
> The Fast CGI standard require that error be reported through the
> FastCGI connection as a Stderr data stream.
> But PHP Fast CGI processes still write errors to original stderr (file
> handle 3) which prevent from clean standard centralized FCGI logging,
> especially when the Fast CGI PHP process is not started by the web
> server (remote Fast CGI).
>
> In most cases, it makes debugging PHP scripts impossible.
>
>
>
> ------------------------------------------------------------------------
>
>
>

-- 
Donate @ http://pecl.php.net/wishlist.php/sniper

---

## #16125 — Sascha Schumann — 2005-04-28T13:55:15+00:00

URL: https://externals.io/message/16123#16125 · In reply to: #16124

Thanks, Jani.

     - Sascha



>
>    I addded fastcgi.logging ini option. Set that to 0 and you'll
>    get the original behaviour back.
>
>    --Jani
>
>
> 
>
> > […]
>
> -- 
> Donate @ http://pecl.php.net/wishlist.php/sniper
