Err(JsonRpc(Transport(SocketError(...))))

[gd87429]

Trying to get basic sample code working with a public hosting provider (quicknode, getblock, etc).

Something like this works when connecting to my personal localhost, but doesn't when connecting to a 3rd party provider:

// let client = Client::new("http://127.0.0.1:8332", Auth::UserPass(...)).ok(); // works
let client = Client::new("https://btc.getblock.io/XXX/mainnet/", Auth::None).ok(); // doesn't work
client.get_blockchain_info().is_ok();

Gives the following:

Err(JsonRpc(Transport(SocketError(Os { code: 54, kind: ConnectionReset, message: "Connection reset by peer" }))))

Even tho this works for both quicknode & getblock.io (API key is correct in code and in curl):

curl --location --request POST 'https://btc.getblock.io/XXX/mainnet/' \
      --header 'Content-Type: application/json' \
      --data-raw '{"jsonrpc": "1.0",
  "method": "getblockchaininfo",
  "params": [],
  "id": ""}'

Any idea what I'm doing wrong in code?

---

tl&dr: Rust w/ localhost works, curl works, rust w/ 3rd-party doesn't work

[apoelstra]

Are you able to try it with master (or #253 (comment) )? We have a pending release which fixes several issues with rust-jsonrpc, and this might be caused by that.

[gd87429]

Thank you for the heads up.

Tried master of bitcoincore-rpc which still throws the same error, but master of bitcoin started throwing all kinds of errors :( Perhaps, either my code is not ready for the upgrades or I'm doing something wrong. Here's a simple reproducible example tho (api key is a trial account).

let url = "https://btc.getblock.io/e7c85cfe-73e1-4657-bf64-1cb4f635a22f/mainnet/".to_string();
let client = Client::new(&url, Auth::None).unwrap();
println!("{:?}", client.get_blockchain_info());

Same thing works in curl:

curl --location --request POST 'https://btc.getblock.io/e7c85cfe-73e1-4657-bf64-1cb4f635a22f/mainnet/' \
      --header 'Content-Type: application/json' \
      --data-raw '{"jsonrpc": "2.0",
  "method": "getblockchaininfo",
  "params": [],
  "id": "hi"}'

[apoelstra]

Ah, thanks! That was super helpful since I could strace both commands to see what they were doing. Though I shouldn't have needed to :)

The problem you're having is that our underlying HTTP crate doesn't support HTTPS at all. We have an open issue to switch to minreq #259 which would let us expose HTTPS support in a couple of ways, but right now we assume we're using bare HTTP 1.1. (The status on that is that I need to contact the maintainers of that crate with a couple mostly-minor things, which I hope to do in the upcoming week.)

If you want to connect over TLS you'll need to stick a proxy in the middle, sorry.

[gd87429]

Ahh that's what it is! Ok, thank you very much for elaborating, makes sense.

I see a lot of activity on a few of these PRs in the last few days. Is it reasonable to wait a few weeks for them to land, or am I better off going the proxy route?

(Closing, since the issue has been found; many thanks for debugging)

[apoelstra]

I see a lot of activity on a few of these PRs in the last few days. Is it reasonable to wait a few weeks for them to land, or am I better off going the proxy route?

I recommend you go the proxy route. There has been a lot of activity but we're working on multiple things at once, and the holiday season is fast approaching, so I don't want to promise meaningful progress on anything quickly :)

[gd87429]

Roger. Thank you very much.