On Thu, 27 Feb 2020 at 02:43, Paul M. Jones <pmjo...@pmjones.io> wrote:
> > 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>). > Why not hope that ReactPHP and others will want to use this object, precisely because it avoids them having to roll their own implementations of things? If your concern is that the object should only wrap up features that are also available via some other mechanism, I'll point again at the $accept array, which AFAIK is a useful piece of parsing which is not available outside the proposed object's constructor. If anything, that's *more* special to this object, because what I'm proposing would directly parallel the existing behaviour of $_POST and $_FILES. If somebody really wanted to use the parser without the rest of the object, they could trivially wrap it in a function: function parse_multipart_form_data($content) { $request = new ServerRequest([], $content); return [ 'input' => $request->input, 'uploads' => $request->uploads ]; } The only downside I can see to adding it is complexity of implementation. But that's at best a reason to say "we'll hope to add this later" rather than "it would be better not to add it". Regards, -- Rowan Tommins [IMSoP]
