Bug #41631 [Com]: default_socket_timeout does not work with SSL

Edit report at https://bugs.php.net/bug.php?id=41631&edit=1 ID: 41631 Comment by: alex at modula-shop-systems dot de Reported by: david at acz dot org Summary: default_socket_timeout does not work with SSL Status: Assigned Type: Bug Package: OpenSSL related Operating System: * PHP Version: 5.2, 5.3 Assigned To: pajoye Block user comment: N Private report: N New Comment: Currently *still* experiencing this on this build of php: PHP 5.4.26-1~dotdeb.0 What is quite ridiculous for a bug that has been reported nearly 7 years ago ! Is it really that difficult to fix this bug? It affects also the SoapClient and makes it quite useless / forces ugly fallbacks to CURL when there is a need to catch timeouts over https. This is really not an uncommon requirement for php in enterprise applications and should simply work. Previous Comments: ------------------------------------------------------------------------ [2013-12-13 09:39:45] lobbin at gmail dot com Honestly, this bug has been open with a potential patch since _2007_. It also contains a perfectly well test case to reproduce the error. ------------------------------------------------------------------------ [2013-03-27 11:48:04] oxygenus at gmail dot com This is taking down my servers as well, everytime some other server is down for maintainance or some network issue occurs. ------------------------------------------------------------------------ [2011-05-12 17:38:18] mgallelli at gmail dot com Hi, i've tested on 5.2.17 and 5.3.2 with the same result. As described i've used this script: time php -n -r 'ini_set("default_socket_timeout", 1); fopen("https://mydomain.it/sleep.php", "r");' but it doesn't wait 1 sec but 15 as into sleep.php page. ------------------------------------------------------------------------ [2011-03-28 23:51:34] arkadi dot shishlov at gmail dot com A simple solution is to use HAProxy to proxy SSL partner services. Works for me. defaults mode tcp contimeout 5000 clitimeout 30000 srvtimeout 30000 listen service.gjensidigebaltic.lv 127.0.0.1:10001 dispatch 193.111.247.167:443 listen services.seesam.lv 127.0.0.1:10007 dispatch 217.28.49.7:443 ------------------------------------------------------------------------ [2011-01-04 00:53:51] guyphp at yahoo dot com This bug has caused us a lot of headaches due to hung connections from partners stacking and eventually taking down entire webservers. During high traffic periods, it doesn't take long for these to reach critical mass. Is there any ETA on when this bug will find its way into stable builds? Like many, our managed hosting provider doesn't support patches - we need a stable build with the fix integrated. We are seeing this problem on 5.2.13, RHEL 5.5. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=41631 -- Edit this bug report at https://bugs.php.net/bug.php?id=41631&edit=1