Re: New Standardized HTTP Interface

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]