php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77929 curl on phpfpm ignore max execution time, time limit and ignore_user_abort
Submitted: 2019-04-21 08:39 UTC Modified: 2019-04-22 07:37 UTC
From: ghislain at ghislain dot net Assigned:
Status: Not a bug Package: PHP options/info functions
PHP Version: 7.2.17 OS: debian8
Private report: No CVE-ID: None
 [2019-04-21 08:39 UTC] ghislain at ghislain dot net
Description:
------------
hi,

  PHP Version 7.2.17-1+0~20190412070953.20+jessie~1.gbp23a36d
System 	Linux  4.9.168-vs2.3.9.8aq #1 SMP Tue Apr 9 13:28:31 CEST 2019 x86_64 

  when using curl_exec on an url that do not answer on php7.2 fpm, the php fpm process can stay open forever if some curl timeout is not set. This means that curl is bypassing all php internal timeout like


set_time_limit
max_execution_time
default_socket_timeout


and even ignore_user_abort.


The only way is to add curl specific time out
//curl_setopt($ch, CURLOPT_TIMEOUT, 10);
//curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);

curl extention should not be able to bypass general php safeguards.

best regards,
Ghislain



Test script:
---------------
<?php

echo date('l jS \of F Y h:i:s A');

// Création d'une nouvelle ressource cURL
$ch = curl_init();

set_time_limit ( 10 ) ;
# Make sure to keep alive the script when a client disconnect.
ignore_user_abort(false);


// Configuration de l'URL et d'autres options
curl_setopt($ch, CURLOPT_URL, "http://myserver.com/curltest.php");
curl_setopt($ch, CURLOPT_HEADER, 0);
//curl_setopt($ch, CURLOPT_TIMEOUT, 10);
//curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);


curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

if(curl_exec($ch) === false)
{
    echo 'Erreur Curl : ' . curl_error($ch);
}
else
{
    echo 'L\'opération s\'est terminée sans aucune erreur';
}


// Fermeture de la session cURL
curl_close($ch);
echo date('l jS \of F Y h:i:s A');
?>


+http://myserver.com/curltest.php =

<?php

sleep( 12000);

?>


Expected result:
----------------
script should stop at 10s or at max execution time.

Actual result:
--------------
stay on until a php-fpm restart

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-04-21 10:03 UTC] spam2 at rhsoft dot net
max_execution_time and "curl extention should not be able to bypass general php safeguards" - well, the url stuff runs in libcurl and PHP has no saying about that and can't measure things running outside the zendengine

max_execution_time is about computing time!
 [2019-04-21 21:52 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2019-04-21 21:52 UTC] requinix@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

As mentioned in the max_execution_time and especially the set_time_limit() docs, on *nix systems the execution time limit only applies while PHP itself is running and does not include (eg) time spent waiting on socket resources.
 [2019-04-22 07:11 UTC] ghislain at ghislain dot net
it would seems logical that php set by default CURLOPT_TIMEOUT to max_execution_time.

but yes, reading the doc completly it say that "Set the number of seconds a script is allowed to run." but in fact it means "set the number of second a script is allowed to run not counting any time spent in any library, extention or external calls".

 That means there is no real protection against scripts doing silly things like i was thinking we had. Sorry for the bothering.

Have a great week !
 [2019-04-22 07:37 UTC] nikic@php.net
This seems a bit odd to me -- shouldn't at least the hard_timeout trigger?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 03:01:28 2024 UTC