Skip to content

[bitreq]: Add blocking Client with connection pooling#518

Open
tnull wants to merge 2 commits intorust-bitcoin:masterfrom
tnull:2026-02-blocking-client
Open

[bitreq]: Add blocking Client with connection pooling#518
tnull wants to merge 2 commits intorust-bitcoin:masterfrom
tnull:2026-02-blocking-client

Conversation

@tnull
Copy link
Collaborator

@tnull tnull commented Feb 25, 2026

Previously, we added a Client allowing for connection reuse behind the async feature. Here we do the same for the blocking, i.e., non-async path.

Add a blocking `Client` that is exposed when the `async` feature is
*not* active. It mirrors the async `Client`'s API: an LRU-evicting
pool of connections keyed by (https, host, port, proxy) that avoids
repeated TCP handshakes and TLS negotiations.

Key implementation details:

- Replace `std::io::Bytes` with a custom `StreamBytes` iterator that
  allows recovering the underlying `HttpStream` via `into_buf_reader`
  after the response body has been fully read.

- Add `Response::create_pooled` which reads the full body and returns
  `Option<HttpStream>` when `Connection: keep-alive` was indicated and
  the `BufReader` buffer is clean.

- Add `Connection::from_stream` and `Connection::send_for_pool` to
  support wrapping a pooled stream and returning it after use.

- The blocking `Client` handles HTTP redirects (301/302/303/307) in a
  loop, reusing the pool for each hop, and parses `Keep-Alive:
  timeout=N` to expire cached connections (default 60s).

- Expose `Client` and `RequestExt` under `#[cfg(feature = "std")]`
  instead of `#[cfg(feature = "async")]` so the appropriate variant
  is available in both configurations.

Co-Authored-By: HAL 9000
Make the `CLIENT` static unconditional and add a `#[cfg(not(feature =
"async"))]` block that exercises the blocking `Client::send()` path,
ensuring the connection-pooling client is tested regardless of feature
configuration.

Co-Authored-By: HAL 9000
Copy link
Collaborator

@oleonardolima oleonardolima left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cACK 94c62c3

It looks good so far, though I won't be able to do a in-depth review and testing until early next week.

Copy link
Member

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, while the code is fine, its really annoying that we're diverging so much between the sync and async code, and even duplicating a decent amount of logic between the sync and sync-connection-reuse logic. Maybe

  • for both sync and async we pass a reference to the Client in so that the Connection can lookup a connection to use on redirect rather than moving that logic out to client.rs.
  • Similar for connection timeouts, I'm fine with it being in Connection or in the Client but let's pick one and stick to it.

/// .send_with_client(&client)?;
/// # Ok(()) }
/// ```
#[cfg(not(feature = "async"))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should never disable code based on a feature being added.

let keep_alive = parent
.headers
.get("connection")
.map_or(false, |h| h.eq_ignore_ascii_case("keep-alive"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ISTM this should live in connection.rs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants