Standard-Timeouts von HTTP-Clients nach Sprache und Bibliothek: keiner, 5 Sekunden oder 100 Sekunden

Worum es geht

Client	Standardwert, wenn kein Timeout gesetzt ist
Python requests	keiner — "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 Sekunden — "raise a TimeoutException after 5 seconds of network inactivity", getrennt angewendet auf Verbindungsaufbau, Lesen, Schreiben und den Bezug einer Verbindung aus dem Pool
Go net/http.Client	insgesamt keiner — "A Timeout of zero means no timeout", und null ist der Zero-Value des Structs; http.DefaultTransport begrenzt nur den Verbindungsaufbau (Dial, 30 s) und den TLS-Handshake (10 s)
.NET HttpClient.Timeout	100 Sekunden — "default value is 100,000 milliseconds"
curl, Verbindungsphase (CURLOPT_CONNECTTIMEOUT, --connect-timeout)	300 Sekunden
curl, gesamte Übertragung (CURLOPT_TIMEOUT, --max-time)	keiner — "0 (zero) which means it never times out during transfer"
axios	keiner — "default is 0 (no timeout)"
Node.js undici und das darauf aufbauende globale fetch (headersTimeout/bodyTimeout)	je 300 Sekunden (300e3 ms), dazu ein connectTimeout von 10 Sekunden; keine Frist für die Gesamtanfrage

Warum es wichtig ist

"Einfach den Standardwert der Bibliothek verwenden" ist nicht sicher, denn die Standardwerte reichen von wenigen Sekunden Toleranz bis zu faktisch unbegrenztem Warten. Die Dokumentation von requests warnt selbst, dass Code ohne Timeout "for minutes or more" hängen kann – in der Praxis unbegrenzt, da das blockierende Verhalten des Betriebssystem-Sockets übernommen wird. Bei Gos http.Client verhält es sich gleich: Ein Timeout-Feld mit Zero-Value, mit dem &http.Client{} startet, bedeutet kein Gesamt-Timeout; der Standard-Transport begrenzt nur den Verbindungsaufbau, sodass ein Server, der die Verbindung annimmt und dann stehen bleibt, den Aufruf offen hält. curl bringt zwei verschiedene Timeout-Optionen mit unterschiedlichen Standardwerten mit: CURLOPT_CONNECTTIMEOUT (300 Sekunden) begrenzt nur die Verbindungsphase – Namensauflösung sowie TCP- und TLS-Handshake –, während CURLOPT_TIMEOUT für die gesamte Anfrage standardmässig null, also unbegrenzt, ist. Ein Skript, das nur eine der beiden Optionen setzt, ist daher nicht gegen einen langsamen, aber verbundenen Server geschützt. axios entspricht mit "no timeout" genau dem Standardwert von curl für das Gesamt-Timeout. httpx ist der Ausreisser in die andere Richtung: Es trennt eine stockende Verbindung standardmässig schon nach 5 Sekunden Inaktivität. Node-undici liegt dazwischen, mit 5 Minuten für die Antwort-Header und 5 Minuten Inaktivität beim Body; eine langsam tröpfelnde Antwort kann damit trotzdem unbegrenzt weiterlaufen.

So wird es angewendet

• Für jeden ausgehenden HTTP-Aufruf eines Agenten ein explizites Timeout setzen; sich nie darauf verlassen, was die Bibliothek "von selbst" tut.
• Bei curl sowohl --connect-timeout als auch --max-time setzen – eines allein lässt die jeweils andere Dimension unbegrenzt.
• Bei httpx das Standard-Timeout von 5 Sekunden für Aufrufe an langsame Upstreams ausdrücklich erhöhen.
• Bei der Fehlersuche unterscheiden zwischen "die Anfrage ist schliesslich mit einem Timeout fehlgeschlagen" und "die Anfrage hängt noch" – Letzteres bedeutet meist, dass die Bibliothek standardmässig gar kein Timeout setzt.

Stolpersteine

• Annehmen, Gos http.Client{} habe ein vernünftiges Standard-Timeout; es hat keines.
• Annehmen, das Connect-Timeout von curl begrenze auch die gesamte Übertragungsdauer.
• Annehmen, httpx und requests teilten einen einheitlichen Standardwert des Python-Ökosystems; das tun sie nicht.