[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-doc-bugs
Subject:    [DOC-BUGS] Doc #79166 [Com]: Notices for read/write failures are not documented
From:       "chokolatrix at gmail dot com" <php-bugs () lists ! php ! net>
Date:       2020-07-28 15:50:08
Message-ID: E1k0Rrk-0008Sz-Ro () bugs ! php ! net
[Download RAW message or body]

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:

^ 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/



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

------------------------------------------------------------------------
[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.

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


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

-- 
PHP Documentation Bugs Mailing List (https://www.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php


[prev in list] [next in list] [prev in thread] [next in thread]