On 6 November 2014 00:31:18 GMT, Andrea Faulds <a...@ajf.me> wrote:
>
>> On 5 Nov 2014, at 22:29, Sherif Ramadan <theanomaly...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
