Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103751
MIME-Version: 1.0
Date: Wed, 16 Jan 2019 08:59:55 +0100
Message-ID: <CADqTB_gq1cj44ndjODNTPCHTJ8ZQS4DtJE=gyG5DG8oqJhSb0A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000060ef0a057f8eaa51"
Subject: Possible bug in the implementation of php://input streams?
From: rasmus@mindplay.dk (Rasmus Schultz)

--00000000000060ef0a057f8eaa51
Content-Type: text/plain; charset="UTF-8"

We've noticed something odd about the "php://input" stream.

This type of stream resource reports itself as seekable:

assert(stream_get_meta_data(fopen("php://input", "r"))["seekable"] ===
true);

https://3v4l.org/EFLiO

If you attempt to rewind() it after reading the stream, rewind() returns
true, and ftell() subequently returns 0.

However, attempting to read the stream again after that returns nothing.

On the other hand, if you fopen() a new resource, it is readable again
after all.

So it seems, either the "php://input" stream implementation is somehow
broken - or it's incorrectly reporting as seekable?

Any idea?

--00000000000060ef0a057f8eaa51--