Module http 

Asynchronous HTTP requests with rate limiting, connection reuse, and bounded responses.

Architecture

HttpClient applies quota policy before delegating requests to InnerHttpClient. The inner client owns one reusable Hyper client, preserving its connection pool across requests and clones.

Rate limiting and requests

Requests can await default and per-key quotas from one or more shared RateLimiter instances. Sharing a limiter across clients enforces one process-wide budget for scopes such as an IP address or account. The client accepts default and per-request headers, repeated query values, raw bodies, and client-level and per-request timeouts.

Proxy routing

By default the client honors ambient proxy configuration: with use_system_proxy left at its default of true and no explicit proxy_url, requests are routed through the proxy named by HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY (lowercase variants included), except destinations matched by NO_PROXY.

This default is a deliberate trust decision on the process environment: an actor who controls it chooses the proxy that observes all plaintext HTTP traffic and the CONNECT tunnels that carry HTTPS.

An optional explicit proxy_url applies to both HTTP and HTTPS traffic and always takes precedence over ambient lookup. Passing use_system_proxy(false) disables ambient lookup, so requests route directly only when proxy_url is unset.

HTTP status errors remain HttpResponse values for adapter-specific handling. The transport retries requests canceled before transmission on reused connections, and allows two retries for remote HTTP/2 GOAWAY(NO_ERROR) or REFUSED_STREAM errors. Other transport failures and HTTP status codes do not trigger retries. Adapters can apply crate::retry::RetryManager when the operation and venue error are safe to retry.

Connection and response policy

Production clients built through HttpClient::builder enable TCP_NODELAY, pooled idle connections, and HTTP/2 keepalive while idle.

HTTP/2 connections use fixed flow-control windows of 16 MiB per stream and 32 MiB per connection, larger than Hyper’s fixed defaults of 2 MiB and 5 MiB. Setting NAUTILUS_HTTP2_ADAPTIVE_WINDOW=true before building a client enables Hyper’s adaptive windows instead, which start at 65,535 bytes and grow toward 16 MiB through PING probes and SETTINGS updates. Cloudflare-fronted endpoints can reset large response bodies mid-transfer under adaptive windows. The value false keeps fixed windows, and any other value fails the build.

Buffered responses retain only configured header fields and reject bodies larger than 100 MiB, including chunked bodies without a declared length. HttpClient::get_stream consumes bodies incrementally without a total size limit. Request URLs in transport errors and response-stream diagnostics are limited to their origin (scheme, host, and port). Setting redact_url(true) on the builder omits the origin too. This policy controls the URL context added by this client; diagnostic messages from lower layers are unchanged. The client logs request metadata only, never URLs.

Hyper owns the lifecycle of individual pooled connections, so this client exposes no socket state sink or explicit reconnect operation. Callers observe connection failure through each request result and retain the client to preserve its pool.

Re-exports

pub use client::HttpClient;

pub use client::HttpRedirectPolicy;

pub use client::InnerHttpClient;

pub use error::HttpClientError;

pub use types::HttpMethod;

pub use types::HttpResponse;

pub use types::HttpStatus;

pub use types::parse_retry_after;

Modules

client

HTTP client implementation with rate limiting and timeout support.

error

HTTP client error types.

types

HTTP types including status codes, methods, and responses.

Structs

HttpResponseStream

An HTTP response whose body is consumed incrementally.

Method

The Request Method (VERB)

StatusCode

An HTTP status code (status-code in RFC 9110 et al.).

Url

A parsed URL record.

Constants

RETRY_AFTER

The Retry-After response HTTP header indicates how long the user agent should wait before making a follow-up request. There are two main cases this header is used:

USER_AGENT

Contains a string that allows identifying the requesting client’s software.

Functions

create_standard_nautilus_headers

Returns the standard headers every NautilusTrader HTTP and WebSocket client sends.