Re: RFC1867 (multipart/form-data) PUT requests

> On Jun 27, 2023, at 04:01, Ilija Tovilo <tovilo.ilija@gmail.com> wrote: > > Hi Ben, Hi Rowan > > On Mon, Jun 26, 2023 at 8:55 PM Ben Ramsey <ben@benramsey.com> wrote: >> >>> On Jun 20, 2023, at 06:06, Rowan Tommins <rowan.collins@gmail.com> wrote: >>> >>> On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo <tovilo.ilija@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

Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc