On 26/02/2020 19:57, Paul M. Jones wrote:
I'm sorry, I'm still having trouble seeing what you're getting at. Do you mean
something like this in the ServerRequest constructor?
public function __construct(array $globals, ?string $content = null)
{
if (
($globals['_POST'] ?? null) === null
&&
strtolower($globals['_SERVER']['CONTENT_TYPE']) ===
'application/x-www-form-urlencoded'
) {
if ($content === null) {
$content = file_get_contents('php://input');
}
$globals['_POST'] = [];
parse_str($content, $globals['_POST']);
}
// ...
}
That's the easy part, yes; the harder part is this:
if (
($globals['_POST'] ?? null) === null
&&
strtolower($globals['_SERVER']['CONTENT_TYPE']) ===
'multipart/form-data'
) {
if ($content === null) {
$content = file_get_contents('php://input');
}
[ $globals['_POST'], $globals['_FILE'] ] =
parse_multipart_form_data($content);
}
Where parse_multipart_form_data is a function which doesn't currently
exist, but whose logic must all be there in the core somewhere, because
everything shows up in $_POST and $_FILES when you process such a request.
Recreating that functionality in userland is non-trivial, but is
essential for several use cases, e.g. an event-based server like
ReactPHP, or a test using a saved request body as a fixture.
If both content types (application/x-www-form-urlencoded and
multipart/form-data) were handled, it would also mean that the
relationship $content -> $input would match the relationship php://input
-> $_POST by default, which seems consistent with the aim of matching
existing behaviour.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
