Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120705
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33
Mime-Version: 1.0
Message-ID: <06cefa3c-a314-415a-9f69-619ddc24b72d@app.fastmail.com>
In-Reply-To: <8FB3E9E9-7240-45BE-B060-C4ACCEDFDC50@koalephant.com>
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>
 <8FB3E9E9-7240-45BE-B060-C4ACCEDFDC50@koalephant.com>
Date: Tue, 27 Jun 2023 19:45:17 -0500
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: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jun 27, 2023, at 3:26 PM, Stephen Reay wrote:
>> On 28 Jun 2023, at 02:53, Ben Ramsey <ben@benramsey.com> wrote:
>>=20
>>> On Jun 27, 2023, at 04:01, Ilija Tovilo <tovilo.ilija@gmail.com> wro=
te:
>>>=20
>>> Hi Ben, Hi Rowan
>>>=20
>>> On Mon, Jun 26, 2023 at 8:55=E2=80=AFPM Ben Ramsey <ben@benramsey.co=
m> wrote:
>>>>=20
>>>>> On Jun 20, 2023, at 06:06, Rowan Tommins <rowan.collins@gmail.com>=
 wrote:
>>>>>=20
>>>>> On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo <tovilo.ilija@gmail.com=
> wrote:
>>>>>=20
>>>>>> Introduce a new function (currently named populate_post_data()) to
>>>>>> read the input stream and populate the $_POST and $_FILES
>>>>>> superglobals.
>>>>>=20
>>>>> How about "request_form_populate_globals"?
>>>=20
>>> The word "form" seems a bit out of place (even though it appears in
>>> both multipart/form-data and application/x-www-form-urlencoded),
>>> because this function is mainly targeted at PUT/PATCH requests for
>>> REST APIs. Maybe request_body_populate_globals?
>>>=20
>>>> Another option for the name: `populate_multipart_form_data()`.
>>>=20
>>> I avoided the term "multipart" because the function technically also
>>> works for application/x-www-form-urlencoded requests. It's less
>>> necessary for the reasons outlined in my previous email, but it would
>>> allow for consistent handling of such requests for all HTTP methods.
>>>=20
>>> Some people on GitHub voiced that they would prefer an INI setting.
>>> Therefore I will create an RFC accordingly.
>>=20
>>=20
>> I know this issue comes up enough because it=E2=80=99s confusing to d=
evelopers that there=E2=80=99s not a `$_PUT`, etc., but I=E2=80=99m not =
a fan of introducing something new that populates globals.
>>=20
>> While I=E2=80=99ve never used `application/x-www-form-urlencoded` dat=
a for `PUT` requests (because I don=E2=80=99t think it=E2=80=99s a prope=
r content-type for the semantics of `PUT`), I do see how this content-ty=
pe could be used with `PATCH`, and I also don=E2=80=99t want to rule-out=
 use cases of it for `PUT` or any other HTTP method.
>>=20
>> In the past, I=E2=80=99ve used something like the following to solve =
this:
>>=20
>>    parse_str(file_get_contents('php://input'), $data);
>>=20
>> I haven=E2=80=99t looked up how any of the frameworks solve this, but=
 I would be willing to bet they also do something similar.
>>=20
>> Rather than implementing functionality to populate globals, would you=
 be interested in introducing some new HTTP request functions. Something=
 like:
>>=20
>>    http_request_body(): string
>>    http_parse_query(string $queryString): array
>>=20
>> `http_request_body()` would return the raw body and would be the equi=
valent of calling `file_get_contents('php://input')`. Of special note is=
 that it should _always_ return the raw body, even if `$_POST` is popula=
ted, for the sake of consistency and reducing confusion.
>>=20
>> `http_parse_query()` would be the opposite of `http_build_query()` an=
d would return a value instead of requiring a reference parameter, like =
`parse_str()`.
>>=20
>> While these don=E2=80=99t address the confusion users face by not hav=
ing a `$_PUT` superglobal, I=E2=80=99d prefer not to overload the superg=
lobals. Maybe we can update the documentation to encourage use of these =
new functions instead of the superglobals?
>>=20
>> We also might want to introduce something like `http_query_string(): =
string` that always returns the raw query string, instead of requiring u=
se of the superglobal `$_SERVER['QUERY_STRING']`.
>>=20
>> Cheers,
>> Ben
>
>
> As a userland/library developer I *much* prefer this approach, but=20
> *please* also include `http_uploads()` (name/signature TBD), returning=20
> an array of file uploads using a structure akin to what $_POST (or=20
> http_parse_query) gives, based on the field name, rather than the=20
> current scenario where the presence of square brackets radically=20
> changes the structure of the $_FILES array.
>
> My initial thought was that perhaps the leaf entities in said array=20
> could be a subclass of SplFileInfo referencing the uploaded temporary=20
> file, with additional read-only properties for the extra upload-relate=
d=20
> attributes - but really the important thing is just having a sane,=20
> consistent structure. Having an object rather than an array with=20
> constant keys would be a nice addition, but is much less important.
>
>
>
> Cheers
>
> Stephen

I also like Ben's suggestion.  It avoids adding more magic globals, but =
also is still simple and straightforward to use in an easily composable =
fashion.  Based on the Content-Type header of the request, it would allo=
w for:

$formData =3D http_parse_query(http_request_body());
$jsonData =3D json_decode(http_request_body());
... Whatever other body parsers.

While you should probably not call it exactly like that, it means "take =
body string, pass to mime-appropriate body parser" is an easy pattern, a=
nd one that can also be easily mocked for testing.

--Larry Garfield