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

Hey All On 28.06.23 02:45, Larry Garfield wrote:

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.

While I like not adding more Superglobals, it seems like we are adding more and more functions to retrieve the different parts of a Request-Object... So when we are at it: Why don't we introduce exactly that? A Request-Object that has all the methods. And which is immutable. And one method request(): \Request I deliberately didn't call it getRequest (or get_request) to not confuse people why there isn't also a post_request or put_request or .. you get the picture) One additional function in global namespace and then we can use one of the request-objects that are already out in the wild. I don't think there's a need to invent the wheel again. The advantage might be that no matter how many calls to request() you will always get the same result. The Request as it came in. Just my 0.02€ Cheers Andreas -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +---------------------------------------------------------------------+

Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc