Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120712
MIME-Version: 1.0
References: <CAPyj-LAabBCvrHUTgO4yoJATmvT0N2Kk7ZpwCb=Vo9aRbz7PtQ@mail.gmail.com>
 <CALKiJKoQudehGwZF9OrB=+rpmpz4My7WR3Fx34GUN2XZL9J1nQ@mail.gmail.com>
 <E7C8FDCD-4333-4D7A-BBB3-C365F9F1D8CA@benramsey.com> <CAPyj-LDnkR+8Y3owNbtT1vgVtBJADE+Y1GTWMiZ8jDSxOZhUgA@mail.gmail.com>
 <15D6E65D-97E3-4F82-8C8A-B8C1FB22D972@benramsey.com>
In-Reply-To: <15D6E65D-97E3-4F82-8C8A-B8C1FB22D972@benramsey.com>
Date: Wed, 28 Jun 2023 14:59:49 +0200
Message-ID: <CAPyj-LDd99AfRnkWEfe1QXQ3LUjWfm94PotXW0mQzG8aWpX_Mg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Ben

On Tue, Jun 27, 2023 at 9:54=E2=80=AFPM Ben Ramsey <ben@benramsey.com> wrot=
e:
>
> > On Jun 27, 2023, at 04:01, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
> >
> > Hi Ben, Hi Rowan
> >
> > On Mon, Jun 26, 2023 at 8:55=E2=80=AFPM Ben Ramsey <ben@benramsey.com> =
wrote:
> >>
> >>> On Jun 20, 2023, at 06:06, Rowan Tommins <rowan.collins@gmail.com> wr=
ote:
> >>>
> >>> On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo <tovilo.ilija@gmail.com> w=
rote:
> >>>
> >>>> Introduce a new function (currently named populate_post_data()) to
> >>>> read the input stream and populate the $_POST and $_FILES
> >>>> superglobals.
>
> In the past, I=E2=80=99ve used something like the following to solve this=
:
>
>     parse_str(file_get_contents('php://input'), $data);
>
> I haven=E2=80=99t looked up how any of the frameworks solve this, but I w=
ould be willing to bet they also do something similar.
>
> Rather than implementing functionality to populate globals, would you be =
interested in introducing some new HTTP request functions. Something like:
>
>     http_request_body(): string
>     http_parse_query(string $queryString): array
>
> `http_request_body()` would return the raw body and would be the equivale=
nt of calling `file_get_contents('php://input')`. Of special note is that i=
t should _always_ return the raw body, even if `$_POST` is populated, for t=
he sake of consistency and reducing confusion.
>
> `http_parse_query()` would be the opposite of `http_build_query()` and wo=
uld return a value instead of requiring a reference parameter, like `parse_=
str()`.

The problem is that the content stream for multipart/form-data is
expected to be big, as in possibly multiple gigabytes big. We can't
use http_request_body() to return the entire content as a string at
once. The current RFC1867 implementation reads and operates in chunks,
i.e. appends it to a file or to a string, depending on the content
part. It never has to hold on to the entire content in memory.
http_request_body() also can't return the content of the request again
after it has been consumed, because that's not how the HTTP protocol
works. We would need to buffer the content somewhere when reading it
for the first time, which again we can't do because it may be very
big.

It may be possible to pass the fopen('php://input', 'r') stream to
this function and let it consume it. However, as mentioned in my
original e-mail this requires some changes to how RFC1867 requests are
handled. Currently, it calls sapi_module.read_post() which directly
reads from the TCP socket. Instead, we'd need to read from the stream,
possibly in addition so that the general case is not degraded in terms
of performance. I'll verify if this is an option, and whether the
changes are (too) big. However, I don't suspect there to be a lot of
use-cases for this as RFC1867 is primarily used for requests and not
for responses, so you wouldn't usually need to parse this type of
content from some other source.

As for returning the parsed values as non-globals, that's entirely
possible. However, it's inconsistent with how requests are currently
handled. The values will need to be passed around manually and kept
alive, but the function still modifies global state (i.e. the input
stream, whether that's sapi_module.read_post() or php://input). I
don't believe it will be common to call this function more than once
per request, and thus decoupling the state is not really necessary.

Ilija