-
Notifications
You must be signed in to change notification settings - Fork 12
Replace reqwest with bitreq #20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ccfa0dd to
5c4b437
Compare
`reqwest` has an absolutely insane dependency tree, with anti-features (like insanely-fast-unsafe-IDN parsing) baked in. Instead, the rust-bitcoin ecosystem is starting to move to `bitreq` which is relatively simple, only depends (even optionally) on `tokio` and `rustls`, and doesn't bother with crap like IDNs. Here we switch over, maintaining the ability to proxy connections for those that need that.
Sadly, we'd exposed `reqwest` in our public API, so we have to bump the version for the swap to `bitreq`.
|
Looks like |
1daa77b to
ec0b296
Compare
tnull
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Makes sense to switch this crate to bitreq already, for other applications I'm still a bit sceptical if its feature set is fully ready yet.
Confirmed failing tests pass locally.
|
|
||
| impl Default for HTTPHrnResolver { | ||
| fn default() -> Self { | ||
| HTTPHrnResolver { client: reqwest::Client::new() } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, seems bitreq has no way to reuse a connection. That might be fine here, but for other applications it seems that might introduce a bunch of unnecessary latency overhead (cf rust-bitcoin/corepc#442).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, for syncing it likely does.
| if let Some(proxy) = &self.proxy { | ||
| req = req.with_proxy(proxy.clone()) | ||
| } | ||
| let resp = req.send_async().await.map_err(|_| ())?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out that this is not actually async but currently just spawns a blocking task (i.e., potentially a thread) per request (cf. rust-bitcoin/corepc#441).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof, yea, that's pretty gnarly...maybe we wait for that to be fixed....let me see if claude can do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, got a PR up for it. Gonna go ahead and land this but we should wait for rust-bitcoin/corepc#448 to release.
reqwesthas an absolutely insane dependency tree, withanti-features (like insanely-fast-unsafe-IDN parsing) baked in.
Instead, the rust-bitcoin ecosystem is starting to move to
bitreqwhich is relatively simple, only depends (even optionally) on
tokioandrustls, and doesn't bother with crap like IDNs.Here we switch over, maintaining the ability to proxy connections
for those that need that.