Not working with HTTP/1.0, f.e. when proxied

[jitash]

hi, i have this error when use quick-node in rust: error: JSON-RPC error: transport error: HTTP response started with HTTP/1.0 ; expected HTTP/1.1 .
anyone can help?

[stevenroose]

Hmm, that's interesting, I don't actually know why we enforce HTTP/1.1 being used..

But what is "quick-node"? You're not using bitcoin core?

[stevenroose]

Oh, is that https://www.quicknode.com/chains/btc? Interesting. So they use some HTTP proxy probably that is using HTTP/1.0.

[jitash]

So, how can I set compatibility with HTTP/1.0?

[gdnathan]

Same issue here

[chinyuchan]

Same issue

[TheBlueMatt]

Uhhh, HTTP/1.1 is from 1997, this is a bug in whatever software is requiring almost 30 year old protocols, not a bug in this library.

[apoelstra]

FWIW, though, it should be fixed upstream by the minreq backend. We had an issue here #259 (see also #276 and #330) which appear to be stalled out. But in principle it should be easy for this library to update their jsonrpc dep.

[scolear]

Same issue on v0.19.

Not sure why quicknode is using HTTP/1.0, alas we can't use it. We are trying to use it as a backup provider for when our bitcoin node is under maintenance. Instead we will spin up another one for the time being.

[adamflush]

You have this backwards, bitcoincore-rpc is using HTTP 1.0 and QuickNode enforces HTTP 1.1+.

Is there a way to force use of a new version of jsonrpc?

[apoelstra]

jsonrpc has never in its history used HTTP 1.0.

You might be able to force a different version using [patch] lines in your Cargo.toml.

And this project is unmaintained.

[adamflush]

rust-bitcoincore-rpc is using HTTP 1.0. What is the fix for that?

It had appeared you had blamed it on a dependency above, but then I misunderstand. How does rust-bitcoincore-rpc get fixed to use HTTP 1.1 or later?

[adamflush]

For what it's worth, just use an HTTP library like reqwest against QuickNode (or other SaSS node providers) and forget about this library. There are so many methods not supported by Node SaSS and often additional and alternative methods not supported by bitcoin RPC.

Example, QuickNode and NowNodes do not support scantxoutset but do support bb_getUTXOs (BTC Book APIs).

[apoelstra]

rust-bitcoincore-rpc is using HTTP 1.0. What is the fix for that?

It is not and never has been.

For what it's worth, just use an HTTP library like reqwest against QuickNode (or other SaSS node providers) and forget about this library.

Who are you talking to?

[adamflush]

Thanks, I stand corrected, the HTTP 1.0 error is just obscuring an HTTP 400 response from QuickNode and the request was indeed HTTP 1.1.

To individuals that may want to use rust-bitcoincore-rpc against QuickNode, you cannot, just use an HTTPS library.

[jpedrosa94]

Same here:
Error fetching network info: JSON-RPC error: transport error: HTTP response started with HTTP/1.0 ; expected HTTP/1.1

[adamflush]

The error message turns out to be incorrect, it's just obfuscating the actual error. Look at the network trace if you can, but the actual error is going to be some message about the RPC method being unsupported by the node with an HTTP 400-599 return code.

Don't use this lib to access non-self-hosted Node RPCs, just access directly.

[jpedrosa94]

I tested the same method through cURL

curl -X POST https://twilight-good-shard.btc-testnet.quiknode.pro/<API_KEY>/ \                09:43:52
-H "Content-Type: application/json" \
-d '{
  "jsonrpc": "1.0",
  "id": "curltest",
  "method": "getnetworkinfo",
  "params": []
}'
{"result":{"version":270100,"subversion":"/Satoshi:27.1.0/","protocolversion":70016,"localservices":"0000000000000c09","localservicesnames":["NETWORK","WITNESS","NETWORK_LIMITED","P2P_V2"],"localrelay":true,"timeoffset":0,"networkactive":true,"connections":107,"connections_in":97,"connections_out":10,"networks":[{"name":"ipv4","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"ipv6","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"onion","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false},{"name":"i2p","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false},{"name":"cjdns","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false}],"relayfee":0.00001000,"incrementalfee":0.00001000,"localaddresses":[],"warnings":"Unknown new rules activated (versionbit 28)"},"error":null,"id":"curltest"}

And it worked. Are you sure the error is due to an unsupported method?

[adamflush]

No, I'm sure that whatever the error is, it is being obscured by the early bailout and incorrect messaging when receiving anything but HTTP 200 response. It can be any error, you'd need to sniff the network traffic (or the library or its dependency needs to avoid obscuring the error).

[PumpkinSeed]

We investigated the issue and there is a possible workaround. Since the bitcoincore_rpc::RpcApi is a trait we could have a custom implementation for the call method.

There is an example for that implementation:

use serde::de::DeserializeOwned;

#[derive(serde::Deserialize, Debug)]
pub struct Wrapper<T> {
    pub id: String,
    pub result: Option<T>,
    pub error: Option<ErrorObject>,
}

#[derive(serde::Deserialize, Debug)]
pub struct ErrorObject {
    pub code: i32,
    pub message: String,
}

pub struct Client {
    pub url: String,
}


impl bitcoincore_rpc::RpcApi for Client {
    fn call<T: DeserializeOwned>(
        &self,
        cmd: &str,
        args: &[serde_json::Value],
    ) -> bitcoincore_rpc::Result<T> {
        let body = serde_json::json!({"jsonrpc": "1.0", "id": "1", "method": cmd, "params": args});
        let mut request = reqwest::blocking::Client::new()
            .post(&self.url)
            .json(&body);

        let res = request.send().unwrap();
        let wrapper: Wrapper<T> = serde_json::from_str(res.text().unwrap().as_str())?;
        Ok(wrapper.result.unwrap())
    }
}

The Client simply implements the bitcoincore_rpc::RpcApi trait and it creates an opt-in replacement for the built-in client. Inside the call method we could implement any custom HTTP call logic, because under the hood the whole library is just a wrapper which helps to send out standardized HTTP requests to the bitcoin daemon.

Note: The code example is unsafe for production since it's lack of proper error handling.