Skip to content

feat(client): HttpClient::from_url_with_addresses for pre-resolved addresses - #14

Merged
casibbald merged 1 commit into
integration/microscaler-forkfrom
feat/client-from-url-with-addresses
Nov 3, 2026
Merged

casibbald merged 1 commit into
integration/microscaler-forkfrom
feat/client-from-url-with-addresses

Conversation

@casibbald

Copy link
Copy Markdown

HttpClient::from_url resolves the host with the system resolver (getaddrinfo). That call blocks the worker OS thread, so every coroutine on that worker waits behind it, and from_url connects without a deadline.

This adds a public constructor that takes already-resolved addresses plus an overall connect timeout. The URL host is still used for the Host header and TLS SNI; https uses the given rustls config or the platform verifier.

Tests: connecting to a .invalid host by address (proves no lookup happens) and rejecting an empty address list. cargo test --features client --lib client_impl passes. Clippy's 4 existing drop_non_drop findings in rich.rs are untouched by this change.

…olved addresses

from_url resolves the URL's host with the operating system resolver
(getaddrinfo), which blocks the whole worker thread rather than the calling
coroutine, and it connects without a deadline. Callers that resolve names off
the worker threads or from a cache had no public way to hand the result in:
the resolved-address constructor was crate-private.

from_url_with_addresses takes the addresses and an overall connect timeout;
the URL's host still sets the Host header and the TLS server name. Tests
connect to a .invalid host by address, and reject an empty address list.
@casibbald
casibbald merged commit 61639cf into integration/microscaler-fork Nov 3, 2026
13 checks passed
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.

1 participant