ID: 39571 User updated by: tim at tmcode dot com Reported By: tim at tmcode dot com Status: Closed Bug Type: Sockets related Operating System: Linux PHP Version: 5CVS-2006-11-21 (CVS) New Comment:
Thank you for the quick fix, it is timing out correctly now. Previous Comments: ------------------------------------------------------------------------ [2006-12-05 01:39:26] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2006-12-04 23:30:27] tim at tmcode dot com Not to be a pain and beat a dead horse but I still think this is a PHP issue. OpenSSL is a very common SSL library. A long list of popular packages such as Curl, wget, links, etc all use openssl. And all of them (that I've taken the time to test) are able to timeout correctly in the situation I've described. Just as an example, a quick look at the libcurl source shows that they use the same technique to timeout the connection as I have described. Granted their code is a little more polished than my patch, but the idea is the same. They put the underlying socket into non-blocking mode, and then loop SSL_connect() until the timeout is reached. Using non-blocking mode to enforce a timeout was how I was taught to do it ages ago in school. If it were a "hack" than I would assume the folks at curl would have done it the right way and patched openssl. The reason this bug is such a problem for me is that we make heavy use of soap calls to other systems. Combine that with heavy traffic and everything snowballs when one of these remote soap servers choke. We can't be the only ones wanting PHP to die gracefully when things go wrong. Having a timeout parameter that doesn't always timeout is a bug. And blaiming it on an underlying library does not change the fact that something that should work in PHP does not. Also, I wasn't clear about the scope of this bug. It does effect *all* https stream related functionalty including file_get_contents, SoapClient, etc. It also prevents max_execution_time from being enforced. ------------------------------------------------------------------------ [2006-12-02 17:04:12] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. It would be one thing to use SSL function or parameter to enforce the timeout, but what you suggest seems like a hack (that may have many stability side-effects) to overcome limitation of the underlying library. My suggestion would be to make a feature request to the OpenSSL folks to add a timeout parameter and once it is there, PHP will certainly use it with the supported version of the lib. ------------------------------------------------------------------------ [2006-11-21 18:04:57] tim at tmcode dot com Heh, no way to support timeouts with openssl? Now thats funny. :) The problem is with SSL_connect() on line 400 of ext/openssl/xp_ssl.c All you have to do is throw the socket into nonblocking mode. Then loop until the timeout has been reached or SSL_connect returns >0. The socket can then be placed back in blocking mode. I have a very quick and dirty patch that does this. Unfortunately it relies on fcntl() so I'm not sure how well it would port off of *nix. If it would help get the bug fixed I would be happy to provide it. ------------------------------------------------------------------------ [2006-11-21 17:16:36] [EMAIL PROTECTED] There is no way to set a timeout on SSL operations which do not support it. ------------------------------------------------------------------------ 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 http://bugs.php.net/39571 -- Edit this bug report at http://bugs.php.net/?id=39571&edit=1
