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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
