Hi Ilija, pt., 13 paź 2023, 13:15 użytkownik Ilija Tovilo <tovilo.il...@gmail.com> napisał:
> Hi everyone > > On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo <tovilo.il...@gmail.com> > wrote: > > https://wiki.php.net/rfc/rfc1867-non-post > > Thank you for the feedback so far. I made a handful of changes to the RFC. > > * The function is renamed to request_parse_body() > * The function will now throw instead of emitting warnings when hitting > limits > * The Configuration section was added show how parsing limits may be > modified per endpoint > * The php://input is explained better in relation to multipart parsing > > Let me know if you have any more feedback. > 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? 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?
