Default HTTP client timeouts by language and library: none, 5 seconds, or 100 seconds

What it is

Client	Default when no timeout is set
Python requests	none — "requests do not time out unless a timeout value is set explicitly. Without a timeout, your code may hang for minutes or more"
Python httpx	5 seconds — "raise a TimeoutException after 5 seconds of network inactivity", applied separately to connect, read, write and pool acquisition
Go net/http.Client	none overall — "A Timeout of zero means no timeout", and zero is the struct's zero value; http.DefaultTransport only bounds dialing (30 s) and the TLS handshake (10 s)
.NET HttpClient.Timeout	100 seconds — "default value is 100,000 milliseconds"
curl, connection phase (CURLOPT_CONNECTTIMEOUT, --connect-timeout)	300 seconds
curl, whole transfer (CURLOPT_TIMEOUT, --max-time)	none — "0 (zero) which means it never times out during transfer"
axios	none — "default is 0 (no timeout)"
Node.js undici and the global fetch built on it (headersTimeout/bodyTimeout)	300 seconds each (300e3 ms), plus a 10-second connectTimeout; no overall request deadline

Why it matters

"Just use the library default" is not safe, because the defaults span from a few seconds of grace to effectively unbounded waiting. requests' own documentation warns that omitting a timeout can hang code "for minutes or more" — in practice, indefinitely, since it inherits the OS socket's blocking behavior. Go's http.Client is the same: a zero-value Timeout field, which is what &http.Client{} starts with, means no overall timeout; the default transport limits only connection setup, so a server that accepts the connection and then stalls holds the call open. curl ships two different timeout knobs with two different defaults: CURLOPT_CONNECTTIMEOUT (300 seconds) bounds only the connection phase — name resolution plus the TCP and TLS handshakes — while CURLOPT_TIMEOUT for the whole request defaults to zero — unlimited — so a script that sets only one of the two is not protected against a slow-but-connected server. axios matches curl's total-timeout default of "no timeout" exactly. httpx is the outlier in the other direction, cutting a stalled connection off after only 5 seconds of inactivity by default. Node's undici sits in between at 5 minutes for the response headers and 5 minutes of body inactivity, which still lets a slowly trickling response run indefinitely.

How to apply

• Set an explicit timeout on every outbound HTTP call an agent makes; never rely on "whatever the library does".
• For curl, set both --connect-timeout and --max-time — one alone leaves the other dimension unbounded.
• For httpx, raise the default 5-second timeout explicitly for calls to slow upstreams.
• Distinguish "the request eventually failed with a timeout" from "the request is still hanging" when triaging — the second usually means the library defaults to no timeout at all.

Pitfalls

• Assuming Go's http.Client{} has a sane default timeout; it has none.
• Assuming setting curl's connect timeout also bounds total transfer time.
• Assuming httpx and requests share one Python-ecosystem-wide default; they do not.