go to bug id or search bugs for
curl_close() does not honor CURLOPT_STDERR if the curl handle has been doing HTTP requests, then it prints 3 lines to the actual stderr, regardless of what CURLOPT_STDERR is set to.
i know PHP 7.0.12 is not affected, so it happened somewhere between 7.0.13 and 7.3.4
php -r '$ch=curl_init();$tmp=tmpfile();curl_setopt_array($ch,array(CURLOPT_VERBOSE=>1,CURLOPT_URL=>"http://gstatic.com/generate_204",CURLOPT_STDERR=>$tmp)); curl_exec($ch);curl_close($ch);fclose($tmp);'
$ php -r '$ch=curl_init();$tmp=tmpfile();curl_setopt_array($ch,array(CURLOPT_VER
* Marked for [closure]: kill all
* Closing connection 0
* The cache now contains 0 members
Add a Patch
Add a Pull Request
Related To: Bug #77939
.. i forgot to add: CURLOPT_VERBOSE also has to be enabled. it is enabled in the test.
on PHP 7.3.5 with Arch Linux x64 with kernel 5.0.13 we only get 1 line:
* Closing connection 0
- that is better, but still bugged.
I cannot reproduce this on Windows 10.0.17763.475, neither with
PHP 7.3.5 nor with current PHP-7.3 tip.
.. i wonder if the libcurl versions here are relevant. firstname.lastname@example.org add the libcurl version you're on (php -i | grep -i curl)
can NOT reproduce on PHP 7.2.15 on Ubuntu 18.04 x64 kernel 4.15.0, libcurl 7.58.0
CAN reproduce on PHP 7.3.4 on Windows 7 x64 SP1, libcurl 7.64.1
CAN (partially) reproduce on PHP 7.3.5 on Arch Linux x64 kernel 5.0.13, libcurl.. ??? (can't check right now, ill make an update when i can)
Those messages are indeed coming directly from cURL, not PHP. There's a variety of hardcoded logging statements in it that should, in theory, be controllable by a compile flag and a runtime flag...
update to above: CAN (partially) reproduce on PHP 7.3.5 on Arch Linux x64 kernel 5.0.13, libcurl 7.64.1
@ email@example.com : those hardcoded logging messages are still supposed to go to CURLOPT_STDERR, not stderr =/
I've used the official build and the official deps,
respectively, i.e. libcurl 7.64.0.
I can indeed reproduce the reported behavior with libcurl 7.64.1
on Debian. Will have a look at the Windows side as soon as
> those hardcoded logging messages are still supposed to go to
> CURLOPT_STDERR, not stderr =/
PHP's CURLOPT_STDERR is a thin wrapper over cURLS's
CURL_OPT_STDERR, so there *might* be a bug in libcurl.
Daniel Stenberg (the libcurl author) says it's probably related to https://curl.haxx.se/mail/lib-2019-05/0021.html
Indeed, if I apply commit d51c7d6 on top of libcurl 7.64.1, no
more spurious output appears. So I don't think there's anything
wrong here on the PHP side.
a PHP userland workaround, run this before calling curl_close:
// workaround for https://bugs.php.net/bug.php?id=78007
curl_setopt_array( $ch, array(CURLOPT_VERBOSE=>0,CURLOPT_URL=>null));
curl_close ( $ch );
.. exactly why i have to call curl_exec(), why it doesn't just work to just set CURLOPT_VERBOSE to 0, i don't know.
Should be fix in upstream libcurl 7.65
@mike indeed, can not reproduce on PHP 7.3.4 with libcurl 7.65.0 :)
So this is not a PHP bug.
Related To: Bug #78162