Weird bug where Typhoeus fails every other request on https

[aselder]

Using Ruby 1.9.2, running in irb

require 'typhoeus'
Typhoeus::Request.get("https://graph.facebook.com/me", :params => {"access_token"=>"139318386102524|83aab471a2..."})
Typhoeus::Request.get("https://graph.facebook.com/me", :params => {"access_token"=>"139318386102524|83aab471a2..."})

The first call to get returns a nice body with my facebook user info. The second call returns

#<Typhoeus::Response:0xd8154cc @code=0, @curl_return_code=60, @curl_error_message="problem with the SSL CA cert (path? access rights?)", @status_message=nil, @http_version=nil, @headers="", @body="", @time=0.148848, @requested_url="https://graph.facebook.com/me?access_token=139318386102524%7C83aab471a217ba2c4764c488.1-748858707%7CDtoWj0bVp-AQ5pOOBFGlJ_bkYKE", @requested_http_method=:get, @start_time=2011-05-24 16:29:45 -0700, @start_transfer_time=nil, @app_connect_time=nil, @pretransfer_time=nil, @connect_time=nil, @name_lookup_time=nil, @request=nil, @effective_url=nil, @mock=false> 

Then if I call it a 3rd time, the proper response is returned, 4th time: bad response, ad infinitum. Odd requests work, even don't.

Running on CentOS:
CentOS release 5.4 (Final)

curl.i386 7.15.5-2.1.el5_3.5 installed
openssl.i686 0.9.8e-12.el5_4.6 installed

[niels]

I have the same issue on CentOS with (lib)curl 7.15. After looking into it in some more, I now suspect the underlying problem is with this libcurl version's curl_easy_reset method because the issue occurs whenever a Typhoeus::Easy instance is reused.

The implementation of the above method differs quite significantly between master (https://github.com/bagder/curl/blob/master/lib/easy.c#L698) and 7.15.5 (https://github.com/bagder/curl/blob/curl-7_15_5/lib/easy.c#L628). In the latter, the CAFILE path is for example explicitly reset to CURL_CA_BUNDLE (as defined upon compile time).

Since this very much looks like the root cause, I first tried updating my curl version. However I also quickly abandoned that to a bunch of dependencies (c-ares, libidn, libssl2) which I didn't care for looking further into. My final "solution" is to just ensure the ssl_cacert option is set for every Typhoeus request. You could for example either directly pass it into get, put, etc. as part of the options hash or overwrite Typhoeus::Request#initialize to always set @ssl_cacert.

I think it is outside of typhoeus' scope to work around the (presumably) underlying problem with libcurl but it would be nice to introduce an easy way to set global options such as for ssl_cacert.

[hanshasselberg]

Can you provide code to reproduce your problem? I'll be happy to reopen if its still an issue.

[stevebissett]

I have encountered this issue now in 2020 with an IG Markets API.

If I run 10 requests with Typhoeus, 5 will fail, and 5 will succeed, every time.
If I use HTTParty, I get 10/10 successes.

Very strange behaviour. I'll collate some steps to reproduce and open a new issue.