php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #78007 curl_close() does not honor CURLOPT_STDERR
Submitted: 2019-05-13 10:41 UTC Modified: 2019-06-06 09:30 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: divinity76 at gmail dot com Assigned: cmb (profile)
Status: Not a bug Package: cURL related
PHP Version: 7.3.5 OS: Windows 7 x64 SP1
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: divinity76 at gmail dot com
New email:
PHP Version: OS:

 

 [2019-05-13 10:41 UTC] divinity76 at gmail dot com 
Description:
------------
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

Test script:
---------------
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);'

Expected result:
----------------
(blank)

Actual result:
--------------
$ 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-05-13 10:49 UTC] divinity76 at gmail dot com 
Related To: Bug #77939
 [2019-05-13 10:55 UTC] divinity76 at gmail dot com 
.. i forgot to add: CURLOPT_VERBOSE also has to be enabled. it is enabled in the test.
 [2019-05-13 11:26 UTC] divinity76 at gmail dot com 
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.
 [2019-05-13 11:32 UTC] cmb@php.net
-Package: Unknown/Other Function +Package: cURL related
 [2019-05-13 11:32 UTC] cmb@php.net 
I cannot reproduce this on Windows 10.0.17763.475, neither with
PHP 7.3.5 nor with current PHP-7.3 tip.
 [2019-05-13 12:26 UTC] divinity76 at gmail dot com 
.. i wonder if the libcurl versions here are relevant. cmb@php.net 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)
 [2019-05-13 12:39 UTC] requinix@php.net 
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...
 [2019-05-13 13:17 UTC] divinity76 at gmail dot com 
update to above: CAN (partially) reproduce on PHP 7.3.5 on Arch Linux x64 kernel 5.0.13, libcurl 7.64.1


@ requinix@php.net : those hardcoded logging messages are still supposed to go to CURLOPT_STDERR, not stderr =/
 [2019-05-13 13:28 UTC] cmb@php.net 
I've used the official build[1] and the official deps[2],
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
possible.

> 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[3], so there *might* be a bug in libcurl.

[1] <https://windows.php.net/download/>
[2] <https://windows.php.net/downloads/php-sdk/deps/series/packages-7.3-vc15-x64-stable.txt>
[3] <https://curl.haxx.se/libcurl/c/CURLOPT_STDERR.html>
 [2019-05-13 13:45 UTC] divinity76 at gmail dot com 
Daniel Stenberg (the libcurl author) says it's probably related to https://curl.haxx.se/mail/lib-2019-05/0021.html
 [2019-05-13 15:35 UTC] cmb@php.net 
Indeed, if I apply commit d51c7d6[1] 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.

[1] <https://github.com/curl/curl/pull/3856/commits/d51c7d63e7e850980553729b4c366f4377308bba>
 [2019-05-13 20:14 UTC] divinity76 at gmail dot com 
a PHP userland workaround, run this before calling curl_close:

<?php
if(true){
	// workaround for https://bugs.php.net/bug.php?id=78007
	curl_setopt_array( $ch, array(CURLOPT_VERBOSE=>0,CURLOPT_URL=>null));
	curl_exec($ch);
}
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.
 [2019-06-06 08:08 UTC] mike@php.net
-Status: Open +Status: Feedback
 [2019-06-06 08:08 UTC] mike@php.net 
Should be fix in upstream libcurl 7.65
 [2019-06-06 09:15 UTC] divinity76 at gmail dot com 
@mike indeed, can not reproduce on PHP 7.3.4 with libcurl 7.65.0 :)
 [2019-06-06 09:30 UTC] cmb@php.net
-Status: Feedback +Status: Not a bug -Assigned To: +Assigned To: cmb
 [2019-06-06 09:30 UTC] cmb@php.net 
So this is not a PHP bug.
 [2019-06-14 17:30 UTC] cmb@php.net 
Related To: Bug #78162
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 13:01:31 2024 UTC