On 09/11/2014 15:10, Rowan Collins wrote:
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,
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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
