rust-networking

Configure timeouts, retries, TLS, and shutdown for production Rust network clients and servers.

2|1|Updated Aug 19, 2026
One-click install
npx skills add https://github.com/po4yka/rust-skills --skill rust-networking-po4yka
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rust-networking
Source: https://github.com/po4yka/rust-skills/tree/main/skills/rust-networking
Command: npx skills add https://github.com/po4yka/rust-skills --skill rust-networking-po4yka

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Rust network stacks like reqwest, hyper, axum, tonic, and rustls ship without timeouts, body limits, or connection bounds, so code that compiles and passes tests can still hang, exhaust memory, or stall shutdown under slow or hostile peers. This Skill provides the concrete limits, retry policies, and verification checks needed to make HTTP, gRPC, WebSocket, and TCP services behave predictably in production. ## Core Features & Use Cases - Operation contract and stack defaults: Define deadline, retry, body-limit, and shutdown decisions up front, then close the specific gaps each crate leaves open (e.g., reqwest's unbounded pool, axum's missing header-read timeout, rustls provider panics). - Safe retry and deadline policy: Implement one absolute deadline across all phases, full-jitter backoff, Retry-After parsing, idempotency checks, and process-wide retry budgets. - Verification and triage: Run ripgrep, cargo tree, and cargo deny checks to find TLS bypasses, unbounded bodies, and vulnerable dependencies, plus a failure-triage table mapping symptoms to causes. - Use Case: While reviewing an axum service, you discover with_graceful_shutdown has no deadline and one slow request can block deploys forever; the Skill shows how to bound it from the shutdown signal and add a header-read timer via hyper-util. ## Quick Start Ask the agent to review your reqwest client or axum server configuration against the rust-networking policy and fix any missing timeouts, body limits, or shutdown deadlines.

Frequently Asked Questions about rust-networking

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set timeouts on a reqwest client in Rust?▼

Reqwest's async client has no default timeout, connect_timeout, or read_timeout, so set each explicitly on the builder. Derive values from the caller's deadline and pass the remaining operation time to RequestBuilder::timeout on every retry attempt.

How do I retry HTTP requests safely in Rust?▼

Retry only idempotent operations with replayable bodies after transient failures, using exponential backoff with full jitter and a small attempt cap. Honor Retry-After, never restart the operation deadline per attempt, and bound retries process-wide with a budget like tower's TpsBudget.

Why does rustls panic with 'Could not automatically determine the process-level CryptoProvider'?▼

This panic happens when zero or two of the ring and aws_lc_rs features are enabled, or custom-provider is on, with no provider installed. Check features with cargo tree -e features -i rustls and install one provider at the top of main before any TLS use.

Does axum apply a header-read timeout by default?▼

No. axum::serve builds its hyper builder with no timer, so hyper's 30-second header_read_timeout never applies and slow-header clients can hold connections. Run the accept loop with hyper-util and set Builder::timer plus header_read_timeout to enforce it.

Why does axum graceful shutdown hang during deploys?▼

with_graceful_shutdown waits for every open connection with no deadline, so one slow request stalls shutdown indefinitely. Bound it from the shutdown signal with a single finite grace period, for example by racing the serve future against a sleep in tokio::select!.

When should a server answer 503 instead of 408 for timeouts?▼

A handler timeout should return 503 or 504, never 408, because 408 tells the client the full request was not received, allowing it to repeat even a POST the handler already ran. Use tower-http TimeoutLayer::with_status_code with SERVICE_UNAVAILABLE.