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

From: Date: Tue, 28 Jul 2020 13:26:17 +0000
Subject: Doc #79166 [Com]: Notices for read/write failures are not documented
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-17738@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
 Comment by:         chokolatrix at gmail dot com
 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
 Operating System:   Windows
 PHP Version:        7.4
 Block user comment: N
 Private report:     N

 New Comment:

> 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


Previous Comments:
------------------------------------------------------------------------
[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.

------------------------------------------------------------------------
[2020-01-27 13:36:33] cmb@php.net

> No notice with the same code on 7.3.

That is to be expected, because that notice is only raised as of
PHP 7.4.0; formerly the write error has been silently ignored.
While this change is documented in the migration guide[1], it is
not yet documented in the manual proper, so I'm re-categorizing as
doc bug.

[1] <https://www.php.net/manual/en/migration74.incompatible.php#migration74.incompatible.core.fread-fwrite>

------------------------------------------------------------------------
[2020-01-27 13:28:52] michael dot piche at csrt dot ulaval dot ca

No notice with the same code on 7.3.

------------------------------------------------------------------------
[2020-01-27 08:03:23] cmb@php.net

I think so.  @michael, what do you mean with

> Everything is working fine with PHP 7.3.

No notice, or did you actually get some output?

------------------------------------------------------------------------
[2020-01-26 16:17:52] nikic@php.net

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

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


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 (#17738) next »