Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
Message-ID: <545FB486.10209@gmail.com>
Date: Sun, 09 Nov 2014 18:37:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com> <CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com> <1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me> <C7BA6728-61DF-4AAF-9270-B8F90F74AF27@gmail.com>
In-Reply-To: <C7BA6728-61DF-4AAF-9270-B8F90F74AF27@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: rowan.collins@gmail.com (Rowan Collins)

On 09/11/2014 15:10, Rowan Collins wrote:
> On 6 November 2014 00:31:18 GMT, Andrea Faulds <ajf@ajf.me> wrote:
>>> On 5 Nov 2014, at 22:29, Sherif Ramadan <theanomaly.is@gmail.com>
>> wrote:
>>>  From all the people I've spoken with that have a problem with
>> handling PUT
>>> requests in PHP, it seems that they'd rather have PHP populate
>>> $_FILES/$_POST automatically in this case. Which would be relatively
>> easy
>>> to do by modifying the default post reader function in the SAPI
>>> http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however,
>> that
>>> is itself a small BC break.
>>>
>>> Does anyone have any recommendations on what they think the best
>> approach
>>> is? I'd appreciate any feedback/suggestions/constructive-criticism.
>> Thanks!
>>
>> I don’t think auto-populating for PUT/DELETE etc. is a good idea,
>> they’re quite different semantically. If I send a DELETE request to
>> code expecting a POST, and PHP pretends it’s a POST request, that’s
>> bad.
>>
>> However, I think the solution is simple: Add a function to do
>> multipart/form-data parsing. Not a suite of functions, not a class,
>> just one simple function. That way, for the few people that need it,
>> they can do $_POST =
>> multipart_form_data_parse(file_get_contents(‘php://input')); and their
>> problem’s solved.
> I haven't caught up with every post in this thread, but I think this is actually the cleanest approach - functions which expose, or behave identically to, the parsing done to populate $_POST and $_FILE
>
> A few weeks back, there was a discussion about supporting a particular binary serialisation format (I forget the name), and it occurred to me that we could have a framework for switching between various encodings, perhaps a bit like ext/filter. For the current case, you might write something like $_POST = decode_from_string(file_get_contents('php://input'), ENC_MULTIPART_FORM_DATA)
>
> It could provide a much-needed decoder for session serialisation (without the awkward side effects of session_decode()), and expose an interface for other extensions to register formats. This would be great for REST applications, because they could pass the incoming content type header to switch() and select a format (and perhaps some optional flags) to pass to the generic decoder.
>
> The actual detail of expected formats, preferred flags, and the destination of the parsed data would be in the PHP application, where it can be easily tweaked, while the hard work of reading through the bytes, which users shouldn't need to modify anyway, would be left to C code. All without the behaviour of the SAPIs themselves having to change at all, as long as php://input is correctly populated.
>
> Regards,

On further reading and thought, perhaps an additional piece that would 
make this feel less like the user having to do all the work themselves 
would be a function which checked the Content-Type and Content-Encoding 
headers and picked an appropriate flag for the decode function 
automatically?

There is definitely a balance to be struck between code which magically 
does the right thing in the majority of cases, and code which can be 
reused in a variety of different recipes - for instance, using a mocked 
HTTP request rather than the information coming out of the SAPI.

-- 
Rowan Collins
[IMSoP]