Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108781
MIME-Version: 1.0
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
 <5904137.fSVIMsojiJ@mcmic-probook> <CDBA02D0-07E1-4723-947C-22B403E650C0@pmjones.io>
 <CA+hqhpcOqCqXuOh3bWavJ+pZ5VVhekUO9LkKgd9c+b98VVnZSA@mail.gmail.com>
 <CAG9XoMRm2Nqjg3UbCc5=1_8m2W7qf8QRoSVk6d_qENJCKE1=9A@mail.gmail.com>
 <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com> <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io>
 <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com> <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io>
 <f58eea0a-6d71-be57-c0b8-abc4321cdb38@gmail.com> <1BF3D29A-04C6-4A82-9216-EAE991A38916@pmjones.io>
 <10388b3a-3402-a6dc-3837-b03d735edf46@gmail.com> <CE336F26-F119-49E6-BD7E-43B47B7F4463@pmjones.io>
 <5ec7b4a7-508b-270b-916f-0504a116196c@gmail.com> <30112AFF-38F9-44D4-9D2F-03A32019764F@pmjones.io>
 <CALKiJKqenOLuUFECKVNPu3ng70q+PGroocWZ7wN1z555Cq-3Mg@mail.gmail.com>
 <A24820E4-55B5-4F50-932B-2D9A92E8C70F@pmjones.io> <be3d4c70-5290-6ca5-a86c-dbee61931dd1@gmail.com>
 <27F45990-E3AE-4A77-85EC-A2CA1EAC73E4@pmjones.io>
In-Reply-To: <27F45990-E3AE-4A77-85EC-A2CA1EAC73E4@pmjones.io>
Date: Thu, 27 Feb 2020 09:43:24 +0000
Message-ID: <CALKiJKpXQAPuRoffRpBKhgfQ63s-6XSSfWJ2epNZniv-3PFcPQ@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000023080c059f8b8eb7"
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000023080c059f8b8eb7
Content-Type: text/plain; charset="UTF-8"

On Thu, 27 Feb 2020 at 02:43, Paul M. Jones <pmjones@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]

--00000000000023080c059f8b8eb7--