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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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 17:01:58 2024 UTC