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

On Tue, Jun 27, 2023, at 3:26 PM, Stephen Reay wrote: >> On 28 Jun 2023, at 02:53, Ben Ramsey <ben@benramsey.com> wrote: >> >>> 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 > > > 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