> On Feb 26, 2020, at 14:12, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On 26/02/2020 19:57, Paul M. Jones wrote:
>
>> Do you mean something like this in the ServerRequest constructor?
>>
>> ...
>
> That's the easy part, yes; the harder part is this:
>
> ...
Yes, that would definitely be the harder part.
> Recreating that functionality in userland is non-trivial, but is essential
> for several use cases, e.g. an event-based server like ReactPHP, or a test
> using a saved request body as a fixture.
>
> If both content types (application/x-www-form-urlencoded and
> multipart/form-data) were handled, it would also mean that the relationship
> $content -> $input would match the relationship php://input -> $_POST by
> default, which seems consistent with the aim of matching existing behaviour.
Yes, it would indeed. However, it strikes me that the thing to do here is not
to try and embed that behavior in ServerRequest; rather, it would be to expose
the existing functionality on its own, so that ReactPHP (and many others!) can
use them, instead of having to roll their own in userland (a la
<https://github.com/reactphp/http/blob/master/src/Io/MultipartParser.php>).
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
