curl_setopt with CURLOPT_POSTFIELDS → Parameter #3 $value of function curl_setopt expects non-empty-string, string given.

[mrohnstock]

Bug report

Since the PR 1719 providing an key-value array to http_build_query and using the return value as 3. parameter to curl_setopt with CURLOPT_POSTFIELDS lead to this issue.

Code snippet that reproduces the problem

https://phpstan.org/r/6d05e5cb-00cf-482d-9021-0c077e2c63bb

Expected output

none error

Did PHPStan help you today? Did it make you happy in any way?

always happy with a new release as many (invisible) issue get's discovered - thank you :D!

[ondrejmirtes]

http_build_query should be modified to return non-empty-string.

[dwenaus]

We are getting this issue as well. we had to disable phpstan until it's fixed because I could not find a work around.
From the logs

##[error]Parameter #3 $value of function curl_setopt expects 0|2, bool given.
##[error]Parameter #3 $value of function curl_setopt expects bool, int given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string|false given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string|false given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
##[error]Parameter #3 $value of function curl_setopt expects bool, int given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
##[error]Parameter #3 $value of function curl_setopt expects non-empty-string, string|false given.

[canvural]

@dwenaus You don't need to disable PHPStan. You can easily ignore the errors until it gets fixed.

[staabm]

@dwenaus please open a separate issue with your code, so we can see which of these errors are legit and which ones are bugs

[dwenaus]

I cannot ignore them via the baseline. They only show up in GitHub actions and not locally. And they came out of the blue. I reran a green branch from a few days ago, zero code changes, and now it fails with the above errors. All branches now fail just like this. But I will ignore them line by line. both local and github action are running phpstan 1.8.4.

[staabm]

Curl types are a opt-in feature atm. These errors only happen when bleedingEdge is enabled.

So you can disable the deature if you need.

We would love to see your code example to get an idea whether the new curl types work as expected

[dwenaus]

Here is how we're using a few of them along with the errors.
Now maybe these are all valid errors! and should be there. either way, this is how we use them. I hope it helps.

        $ch = curl_init();
        curl_setopt(...);

        // Parameter #3 $value of function curl_setopt expects 0|2, bool given.
        curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);

        // Parameter #3 $value of function curl_setopt expects bool, int given.
        curl_setopt($ch, CURLOPT_POST, 1);

        // Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
        curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query(['name' => 'blah'])); 

From another page:

        $ch = curl_init();
        curl_setopt($ch, CURLOPT_HTTPHEADER, $this->headers);

        // Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
        curl_setopt($ch, CURLOPT_URL, $url);

        // Parameter #3 $value of function curl_setopt expects bool, int given.
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

        // Parameter #3 $value of function curl_setopt expects non-empty-string, string given.
        curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');

        //Parameter #3 $value of function curl_setopt expects non-empty-string, string|false given.
        curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data['json']));

There were a number of CURLOPT_* that were working fine without error, so I did not include them.

[dwenaus]

But there is another bug somewhere because these errors show up on github actions but not locally, all using the same config and same version of phpstan.

Thanks for the tip about bleeding edge. Maybe we'll turn that off to get more stability.

[jlherren]

Hold on... CURLOPT_POSTFIELDS should definitely accept empty strings, because the empty string is the correct way to www-form-urlencode the empty array, as in, not submitting any values. The following code works exactly as expected:

$curl = curl_init('https://example.com/data-receiver');
assert($curl !== false);
curl_setopt($curl, CURLOPT_POST, true);
curl_setopt($curl, CURLOPT_POSTFIELDS, '');
curl_setopt($curl, CURLOPT_HTTPHEADER, ['Content-Type: application/x-www-form-urlencoded']);

https://phpstan.org/r/a08f7b38-cffc-4dde-ab23-c5641d03f305

[wpmvangroesen]

The php documentation states the following. CURLOPT_POSTFIELDS could be a string, empty string or an array. So these type hints in the bleeding edge actually don't make any sense (yet). Would be nice to fully support the curl options, but implementation would need some more attention to detail.

The full data to post in a HTTP "POST" operation. This parameter can either be passed as a urlencoded string like 'para1=val1&para2=val2&...' or as an array with the field name as key and field data as value. If value is an array, the Content-Type header will be set to multipart/form-data. Files can be sent using CURLFile or CURLStringFile, in which case value must be an array.

[ondrejmirtes]

Feel free to fix the typehints :) Here's the original PR phpstan/phpstan-src#1719. You might find this documentation helpful: https://phpstan.org/developing-extensions/type-system

[VincentLanglet]

I'll try to fix this phpstan/phpstan-src#1777

[ondrejmirtes]

Fixed by phpstan/phpstan-src#1782

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.