Re: RFC: Server-Side Request and Response Objects (v2)

> On Feb 26, 2020, at 14:12, Rowan Tommins <rowan.collins@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 pmjones@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