Re: Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs

Hi On 10/13/23 17:59, Michał Marcin Brzuchalski wrote:

Considering the function supports two formats multipart/form-data or the application/x-www-form-urlencodedand the fact that the return type and required arguments differ in regards to format: content-type needed for multipart which returns two arrays packed into return array aka $_POST and $_FILES and the boundary that is part of content-type header and the other format that doesn't require content-type header and returns effectively only one array aka $_POST why not having two separate functions?

Because then you can't just [$fields, $files] = request_parse_body($request->getBody(), $request->getHeader('content-type')); $request = $request->withParsedBody($fields); (using a PSR-7 ServerRequestInterface object for the example) and instead would need to manually parse the 'content-type' header instead of leaving the heavy lifting to PHP.

The proposal is to include two separate functions that have clear semantics and prevent from invoking multipart without boundary or only form with boundary: * request_parse_body($input_stream): array - returning just $_POST and maybe * request_parse_multupart_body($input_stream, string $boundary): array returning as proposed now two arrays packed $_POST and $_FILES Why the $inpit_stream accepts null - does it make sense to invoke the function then?

Yes, because it effectively defaults to an optimized version of 'php://input'. Best regards Tim Düsterhus