Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121303
Message-ID: <99ebd4db-18ae-42bb-9d96-388e59fa35ad@bastelstu.be>
Date: Fri, 13 Oct 2023 19:15:55 +0200
MIME-Version: 1.0
To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=
 <michal.brzuchalski@gmail.com>, Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <CAPyj-LD0EDYUZSOM=P9doSZRJ8LipSKKUSBHxV-bRbCV1QsYtQ@mail.gmail.com>
 <CAPyj-LD5=SDXmP5EhR-hfL-FreXXey-CGGoHcqEYq1z44YKRbA@mail.gmail.com>
 <CABdc3WpkWBFNao3A_+RQ9b-dXU74YivcwAaUu-yJ=Fmj1D4h0A@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CABdc3WpkWBFNao3A_+RQ9b-dXU74YivcwAaUu-yJ=Fmj1D4h0A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC][Under discussion] RFC1867 for non-POST HTTP
 verbs
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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