Doc #79166 [Ver]: Notices for read/write failures are not documented

From: Date: Thu, 06 Oct 2022 10:51:43 +0000
Subject: Doc #79166 [Ver]: Notices for read/write failures are not documented
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-19477@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=79166&edit=1

 ID:                 79166
 Updated by:         bukka@php.net
 Reported by:        michael dot piche at csrt dot ulaval dot ca
 Summary:            Notices for read/write failures are not documented
 Status:             Verified
 Type:               Documentation Problem
-Package:            Streams related
+Package:            CGI/CLI related
 Operating System:   Windows
 PHP Version:        7.4
 Block user comment: N
 Private report:     N

 New Comment:

This might need some investigation on SAPI level as FPM deals with this just fine on Linux so would
be good if someone properly look if the same can be done on Windows. In any case this is a SAPI
issue really so the documentation would be SAPI related anyway.


Previous Comments:
------------------------------------------------------------------------
[2020-08-18 18:04:04] michael dot piche at csrt dot ulaval dot ca

> If it isn't possible to write to php://stderr, shouldn't the fopen return FALSE ?

My bug report isn't related to documentation. https://bugs.php.net/bug.php?id=79905 seems like
the same bug.

------------------------------------------------------------------------
[2020-07-28 15:50:08] chokolatrix at gmail dot com

^ I've wrongly quoted *mod_fastcgi* documentation, but I've only tested *mod_fcgid*. 

Haven't found references to logging or stderr in the *mod_fcgid* documentation [1]. 
There are various posts on the web [2] [3] quoting Apache logs containting "mod_fcgid: stderr:
..." so it must work in some combination of OS + Apache + PHP.

[1] https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
[2] https://wordpress.org/support/topic/mod_fcgid-stderr-php-warning-exif_read_dataimg_0113-jpg/
[3] https://wordpress.org/support/topic/mod_fcgid-stderr-php-fatal-error-allowed-memory-size-exhausted/

------------------------------------------------------------------------
[2020-07-28 13:35:27] chokolatrix at gmail dot com

^ I messed-up the links order ¯\_(ツ)_/¯

------------------------------------------------------------------------
[2020-07-28 13:26:17] chokolatrix at gmail dot com

> To clarify, the bug here is that you can open php://stderr despite the webserver SAPI
> presumably not having an stderr FD?

I think this report was created because of lacking documentation. I've opened #79905 [1]
"fopen() read-only streams in write mode doesn't fail" which I think is a bug.

If my understanding is correct, stderr should go to Apache's error log as stated by it's
docs (see below). PHP failing to write to stderr in FCGI context might be an Apache bug.

Apache 1.3 docs [2]: "Any information written to stderr by a CGI script will be copied directly
to the error log" - it also applies to FCGI?

Mod_fastcgi docs [3]: "mod_fastcgi logs FastCGI application error (stderr) output to the server
log associated with the request. Errors reported by the FastCGI process manager, fcgi-pm, are
reported to the main server log (typically, logs/error_log). Data written to stdout or stderr before
entering the FastCGI accept loop or via a mechanism that is not FastCGI protocol aware will also be
directed to the main server log"
 

[1] https://httpd.apache.org/docs/1.3/logs.html
[2] https://fastcgi-archives.github.io/mod_fastcgi.html
[3] https://bugs.php.net/bug.php?id=79905

------------------------------------------------------------------------
[2020-01-27 13:48:00] michael dot piche at csrt dot ulaval dot ca

If it isn't possible to write to php://stderr, shouldn't the fopen return FALSE ? 

The notice come from Logger class in Symfony and there is a verification if the stream is a
ressource, with is the case.

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


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=79166


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


Thread (8 messages)

« previous php.doc.bugs (#19477) next »