Doc #79905 [Opn]: Console-less environments do not prevent std streams to be opened

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

 ID:                 79905
 Updated by:         [email protected]
 Reported by:        chokolatrix at gmail dot com
 Summary:            Console-less environments do not prevent std streams
                     to be opened
 Status:             Open
 Type:               Documentation Problem
-Package:            Filesystem function related
+Package:            CGI/CLI related
 Operating System:   WINDOWS
 PHP Version:        7.4.8
 Block user comment: N
 Private report:     N

 New Comment:

So this is specific to CGI SAPI and it might be also good to check if it can do the same thing on Windows as FPM does on Linux - it means redirect those streams to be still usable.


Previous Comments:
------------------------------------------------------------------------
[2021-12-14 11:45:06] [email protected]

> The fact that PHP allows to open php://stderr is certainly a bug
> in this case.

While that is indeed not nice, and could be prevented, the more
serious issue is that php://stdin can be opened, but reading from
it would likely hang indefinitely under FCGI, since stdin is
actually FCGI_LISTENSOCK_FILENO (i.e. a pipe on Windows), and
detecting this is non-trivial, unless we would expose that info
from the SAPIs.

It's probably best to leave the implementation as is, and to
document the limitation instead.

------------------------------------------------------------------------
[2021-12-09 17:54:28] [email protected]

> The fact that opening the 'output', 'input', 'stdin', 'stderr' and
> 'fd' protocols completly ignores the given $mode[1], looks
> actually wrong to me.

On further consideration, I don't think that qualifies as a bug;
it is merely something to be documented, and that has been
done[1].  Emitting a notice if a mode is passed which does not
match, might be an improvement, but is not strictly necessary.

It is also not necessary to give an option to open php://stderr in
read-write mode; while POSIX mandates[2] that stderr is expected
to be open for reading and writing, this is not supported on
Windows, and likely there is no real need for that.  Furthermore,
on CLI, STDERR could be used instead, what is supposed to follow
POSIX semantics on POSIX conforming platforms.

[1] <https://github.com/php/doc-en/commit/c5c3a4153df3b8c8007a33488f676e31b8e0f906>
[2] <https://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html>

------------------------------------------------------------------------
[2020-09-22 09:15:02] [email protected]

Related To: Bug #76086

------------------------------------------------------------------------
[2020-07-30 12:56:20] [email protected]

The fact that opening the 'output', 'input', 'stdin', 'stderr' and
'fd' protocols completly ignores the given $mode[1], looks
actually wrong to me.

However, on Windows with IIS *F*CGI there is usually no stderr
(nor stdout for that matter); all communication with the Webserver
is done through a pipe.  The fact that PHP allows to open
php://stderr is certainly a bug in this case.

[1] <https://github.com/php/php-src/blob/php-7.4.8/ext/standard/php_fopen_wrapper.c#L215-L341>

------------------------------------------------------------------------
[2020-07-28 12:08:30] chokolatrix at gmail dot com

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

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


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=79905


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