Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120703
Content-Type: multipart/signed;
	boundary="Apple-Mail=_39A33067-6DA5-40C3-9471-88DC5107E7ED";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
In-Reply-To: <CAPyj-LDnkR+8Y3owNbtT1vgVtBJADE+Y1GTWMiZ8jDSxOZhUgA@mail.gmail.com>
Date: Tue, 27 Jun 2023 14:53:59 -0500
Cc: PHP internals <internals@lists.php.net>
Message-ID: <15D6E65D-97E3-4F82-8C8A-B8C1FB22D972@benramsey.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>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Subject: Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_39A33067-6DA5-40C3-9471-88DC5107E7ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> 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.


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.

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.

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 =
would 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 =
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.

`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()`.

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?

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']`.

Cheers,
Ben


--Apple-Mail=_39A33067-6DA5-40C3-9471-88DC5107E7ED
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCZJs+VwAKCRCwLZeYnIwH
G31hAP9RnhBdcpaEj06UrKiaScSLJPMjE1E0QUQbYOiNdMMPJwD/R1jXiRHLnVNf
tOBiENu2jdywLaW0v2ksPLj+qFVKSZ0=
=2dPG
-----END PGP SIGNATURE-----

--Apple-Mail=_39A33067-6DA5-40C3-9471-88DC5107E7ED--