I am having a strange problem with the below php function. Unfortunately this is one of those special \"Production only\" case.
function requestPost($url, $data)
add the following at the end your script to get the cause of failure
if( $rawresponse === false )
syslog( LOG_INFO , "base.php::requestPost() : ".curl_error($curlSession) );
EDIT 1
It could be an internal problem of curl. Before all check all server runtimes are up to date ( php, php-curl and apache at least). Check all their logs..... Then I would recommand comparing results between several production environment or a dev/test environment.
Finally try to narrow down a minimal testcase that could reproduce your issue and publish full code for the test case.
Have you tried installing a different version of apache and php? Do you have them in the package manager? If not, try compiling the latest apache, php and curl manually and see if you get the same result.
The problem was NSS. I recompiled curl with OpenSSL and so far it has not shown any issues.
Cheers!
If curl_exec
hangs, then it may be because of a DNS problem or a redirection loop. In other words, there may be nothing wrong with the function, but with the network route of your request. May be a deadlock with a localhost loop.
Cheers!
NSS is more strict than either OpenSSL or GnuTLS. Fedora/RHEL curl defaults to using NSS over OpenSSL, and can catch errors that don't arise using curl on OSX, Ubuntu, etc.
Here's a list of NSS error codes http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html
[root@mybox ~]# curl -k -v -E /etc/mycert.pem https://127.0.0.1/
* About to connect() to 127.0.0.1 port 443 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* NSS error -8054
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
The stack trace clearly shows that the break you did occur within the NSS crypto library that your libcurl is built to use for SSL.
libcurl has got a lot of NSS-related fixes since the libcurl version you use, and possibly you're not using the most up-to-date NSS either. I would strongly suggest that you consider upgrading to the latest and greatest before you pull all your hair out on this problem.
To debug this problem, I would recommend you try to repeat it with the curl command line from the same server, and make good use of the --trace-ascii command.