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

On 26/02/2020 19:57, Paul M. Jones wrote:

I'm sorry, I'm still having trouble seeing what you're getting at. Do you mean something like this in the ServerRequest constructor?

     public function __construct(array $globals, ?string $content = null)
     {
         if (
             ($globals['_POST'] ?? null) === null
             &&
             strtolower($globals['_SERVER']['CONTENT_TYPE']) === 'application/x-www-form-urlencoded'
         ) {
             if ($content === null) {
                 $content = file_get_contents('php://input');
             }
             $globals['_POST'] = [];
             parse_str($content, $globals['_POST']);
         }

         // ...
     }

That's the easy part, yes; the harder part is this:

        if (
            ($globals['_POST'] ?? null) === null
            &&
            strtolower($globals['_SERVER']['CONTENT_TYPE']) === 'multipart/form-data'
        ) {
            if ($content === null) {
                $content = file_get_contents('php://input');
            }
            [ $globals['_POST'], $globals['_FILE'] ] = parse_multipart_form_data($content);
        }

Where parse_multipart_form_data is a function which doesn't currently exist, but whose logic must all be there in the core somewhere, because everything shows up in $_POST and $_FILES when you process such a request. 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. Regards, -- Rowan Tommins (né Collins) [IMSoP]