So I have been trying to figure this one out for about a week now. Here is the run down:
I use CURL in PHP to pull data from an API. As the response to the API call gets bigger (pulling over 15k records at once) I noticed that any API call that takes 5 or more minutes (within a few seconds) fails to return on my CentOS and Suse servers. So, I tested the API call from the CLI via CURL and I get the same issue. Oddly, if I run the CURL command via OS X the command runs fine and returns after ~7 or so minutes.
Here is the command (creds censored) I am running via CURL:
curl -m 0 -k --trace-ascii trace.txt --trace-time -X GET -H "tenant-code: 1cmPx7tqVDVTdN1GSelwycFUmICmASnLCmNQsV72" -H "Authorization: Basic JxHAsXeUiHMRkS8Msiu6pWb3PvY20p6am3QvXCY3knXTAntlxTBS3EyEDgly" -H "Content-Type: application/json" -H "Cache-Control: no-cache" 'https://api.endpoint.com/API/v1/system/users/search?groupid=555' > dump.txt
And here is the version output from CURL for each platform:
CentOS (this is where I really need this to work)-
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1 SecureTransport zlib/1.2.5 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
And these are the error codes I get from Centos:
curl: (56) SSL read: errno -5961
I can't find that code referenced in the documentation. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/sslerr.html
I get a slightly different error from Suse:
curl: (52) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
The error 104 lead me to believe that the server is stopping/resetting the connection but the server side logs don't show it being dropped and OS X can pull the data without an issue. I even tried spoofing the User Agent to make sure that was not the issue.
So, at this point I assume that the SSL package SecureTransport is doing something that OpenSSL and NSS are not doing. The question is what and if not, what is the issue?