On Tue, Jun 27, 2023, at 3:26 PM, Stephen Reay wrote:
>> On 28 Jun 2023, at 02:53, Ben Ramsey <b...@benramsey.com> wrote:
>>
>>> 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
>
>
> 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
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 allow for:
$formData = http_parse_query(http_request_body());
$jsonData = 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, and one that
can also be easily mocked for testing.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
