Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78855
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me>
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>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sun, 09 Nov 2014 15:10:31 +0000
To: PHP Internals <internals@lists.php.net>
Message-ID: <C7BA6728-61DF-4AAF-9270-B8F90F74AF27@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: rowan.collins@gmail.com (Rowan Collins)

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,
-- 
Rowan Collins
[IMSoP]