We could add a flag to disable the @ usage but I'm against having the
'@' usage disabled by default. This BC break would be in my opinion
too big.
An other solution would be to have something like (We will also have
to add the type and filename support to this solution so this is just
a first proposal) :
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFIELDS, array(
'firstname' => 'pierrick',
'lastname' => array(CURL_FORMSTR, 'charron'),
'lastname' => array(CURL_FORMFILE, '/home/pierrick/picture.png')
);
Pierrick
Otherwise the safest way for people is to use http_build_query on
their parameter array.
Pierrick
On 11 March 2012 19:29, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi!
>
>> I'd sure like a PHP extension that didn't have this obvious and nasty bug:
>>
>> https://bugs.php.net/bug.php?id=46439
>
>
> This doesn't look good. Documentation does say the @ prefix exists, but it
> has very high potential of creating security holes for unsuspecting people.
> open_basedir would help limit the impact, but still it's not a good thing.
> Any ideas on fixing it without breaking the BC?
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
