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

> 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