Everything

php

Home » Project » Newsgroups » php.internals » Possible bug in the implementation of php://input streams? »

Possible bug in the implementation of php://input streams?

php.internals

Rasmus Schultz

7 years ago

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?

Lauri Kenttä

7 years ago

On 2019-01-16 09:59, Rasmus Schultz wrote:

> We've noticed something odd about the "php://input" stream.
>
> 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.

It has so many layers of redirection that someone missed setting
stream->position on one layer.

Maybe someone would care to apply the attached patch to fix this.

--
Lauri Kenttä

Nikita Popov

7 years ago

On Wed, Jan 16, 2019 at 9:16 PM Lauri Kenttä <lauri.kentta@gmail.com> wrote:

> On 2019-01-16 09:59, Rasmus Schultz wrote:
> > We've noticed something odd about the "php://input" stream.
> >
> > 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.
>
> It has so many layers of redirection that someone missed setting
> stream->position on one layer.
>
> Maybe someone would care to apply the attached patch to fix this.
>

Thanks Lauri, I have applied your patch to PHP 7.2 and up.

Nikita