Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120704
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_17BEE87D-B0C3-46E9-A5EF-292D18357BC0"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Wed, 28 Jun 2023 03:26:21 +0700
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>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <15D6E65D-97E3-4F82-8C8A-B8C1FB22D972@benramsey.com>
Message-ID: <8FB3E9E9-7240-45BE-B060-C4ACCEDFDC50@koalephant.com>
Subject: Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests
From: php-lists@koalephant.com (Stephen Reay)

--Apple-Mail=_17BEE87D-B0C3-46E9-A5EF-292D18357BC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> 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> =
wrote:
>>=20
>> Hi Ben, Hi Rowan
>>=20
>> On Mon, Jun 26, 2023 at 8:55=E2=80=AFPM Ben Ramsey =
<ben@benramsey.com> 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 =
developers 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` data =
for `PUT` requests (because I don=E2=80=99t think it=E2=80=99s a proper =
content-type for the semantics of `PUT`), I do see how this content-type =
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 =
equivalent of calling `file_get_contents('php://input')`. Of special =
note is that it should _always_ return the raw body, even if `$_POST` is =
populated, for the sake of consistency and reducing confusion.
>=20
> `http_parse_query()` would be the opposite of `http_build_query()` and =
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 =
having a `$_PUT` superglobal, I=E2=80=99d prefer not to overload the =
superglobals. 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 =
use of the superglobal `$_SERVER['QUERY_STRING']`.
>=20
> Cheers,
> Ben


As a userland/library developer I *much* prefer this approach, but =
*please* also include `http_uploads()` (name/signature TBD), returning =
an array of file uploads using a structure akin to what $_POST (or =
http_parse_query) gives, based on the field name, rather than the =
current scenario where the presence of square brackets radically changes =
the structure of the $_FILES array.

My initial thought was that perhaps the leaf entities in said array =
could be a subclass of SplFileInfo referencing the uploaded temporary =
file, with additional read-only properties for the extra upload-related =
attributes - but really the important thing is just having a sane, =
consistent structure. Having an object rather than an array with =
constant keys would be a nice addition, but is much less important.



Cheers

Stephen=20=

--Apple-Mail=_17BEE87D-B0C3-46E9-A5EF-292D18357BC0--