Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108777
To: php internals <internals@lists.php.net>
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>
Message-ID: <be3d4c70-5290-6ca5-a86c-dbee61931dd1@gmail.com>
Date: Wed, 26 Feb 2020 20:12:00 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <A24820E4-55B5-4F50-932B-2D9A92E8C70F@pmjones.io>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: rowan.collins@gmail.com (Rowan Tommins)

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]