> On Jun 27, 2023, at 04:01, Ilija Tovilo <tovilo.il...@gmail.com> wrote: > > Hi Ben, Hi Rowan > > On Mon, Jun 26, 2023 at 8:55 PM Ben Ramsey <b...@benramsey.com> wrote: >> >>> On Jun 20, 2023, at 06:06, Rowan Tommins <rowan.coll...@gmail.com> wrote: >>> >>> On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo <tovilo.il...@gmail.com> wrote: >>> >>>> Introduce a new function (currently named populate_post_data()) to >>>> read the input stream and populate the $_POST and $_FILES >>>> superglobals. >>> >>> How about "request_form_populate_globals"? > > 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? > >> Another option for the name: `populate_multipart_form_data()`. > > 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. > > 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’s confusing to developers that
there’s not a `$_PUT`, etc., but I’m not a fan of introducing something new
that populates globals.
While I’ve never used `application/x-www-form-urlencoded` data for `PUT`
requests (because I don’t think it’s 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’t want to rule-out use cases of it for `PUT` or any other HTTP method.
In the past, I’ve used something like the following to solve this:
parse_str(file_get_contents('php://input'), $data);
I haven’t 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’t address the confusion users face by not having a `$_PUT`
superglobal, I’d 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
signature.asc
Description: Message signed with OpenPGP
