Délais d'expiration par défaut des clients HTTP selon le langage et la bibliothèque : aucun, 5 secondes ou 100 secondes

Ce que c'est

Client	Valeur par défaut si aucun timeout n'est défini
Python requests	aucune — "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 secondes — "raise a TimeoutException after 5 seconds of network inactivity", appliquées séparément à la connexion, à la lecture, à l'écriture et à l'obtention d'une connexion dans le pool
Go net/http.Client	aucune limite globale — "A Timeout of zero means no timeout", et zéro est la valeur zéro de la structure ; http.DefaultTransport ne borne que l'établissement de la connexion (30 s) et la négociation TLS (10 s)
.NET HttpClient.Timeout	100 secondes — "default value is 100,000 milliseconds"
curl, phase de connexion (CURLOPT_CONNECTTIMEOUT, --connect-timeout)	300 secondes
curl, transfert complet (CURLOPT_TIMEOUT, --max-time)	aucune — "0 (zero) which means it never times out during transfer"
axios	aucune — "default is 0 (no timeout)"
Node.js undici et le fetch global qui s'appuie dessus (headersTimeout/bodyTimeout)	300 secondes chacun (300e3 ms), plus un connectTimeout de 10 secondes ; pas de délai limite global pour la requête

Pourquoi c'est important

« Utiliser simplement la valeur par défaut de la bibliothèque » n'est pas sûr, car ces valeurs vont de quelques secondes de tolérance à une attente pratiquement illimitée. La documentation de requests avertit elle-même que l'absence de timeout peut bloquer le code « pendant des minutes, voire plus » ("for minutes or more") — en pratique indéfiniment, puisque le comportement bloquant du socket du système d'exploitation est hérité. Il en va de même pour http.Client en Go : un champ Timeout à sa valeur zéro, ce qui est le cas avec &http.Client{}, signifie qu'il n'y a pas de timeout global ; le transport par défaut ne limite que l'établissement de la connexion, de sorte qu'un serveur qui accepte la connexion puis se fige garde l'appel ouvert. curl propose deux paramètres de timeout distincts, avec deux valeurs par défaut différentes : CURLOPT_CONNECTTIMEOUT (300 secondes) ne borne que la phase de connexion — résolution de nom, puis négociations TCP et TLS —, tandis que CURLOPT_TIMEOUT, qui porte sur la requête entière, vaut zéro par défaut, c'est-à-dire sans limite ; un script qui ne définit que l'un des deux n'est donc pas protégé contre un serveur connecté mais lent. axios correspond exactement à la valeur par défaut de curl pour le timeout total : aucun timeout. httpx fait figure d'exception dans l'autre sens : par défaut, il coupe une connexion bloquée après seulement 5 secondes d'inactivité. undici de Node se situe entre les deux, avec 5 minutes pour les en-têtes de réponse et 5 minutes d'inactivité pour le corps, ce qui permet encore à une réponse qui arrive goutte à goutte de se prolonger indéfiniment.

Comment l'appliquer

• Définir un timeout explicite pour chaque appel HTTP sortant effectué par un agent ; ne jamais s'en remettre à « ce que fait la bibliothèque ».
• Avec curl, définir à la fois --connect-timeout et --max-time : l'un seul laisse l'autre dimension sans limite.
• Avec httpx, relever explicitement le timeout par défaut de 5 secondes pour les appels vers des services amont lents.
• Lors du diagnostic, distinguer « la requête a fini par échouer sur un timeout » de « la requête est toujours bloquée » — le second cas signifie généralement que la bibliothèque n'applique aucun timeout par défaut.

Pièges

• Supposer que http.Client{} de Go a un timeout par défaut raisonnable ; il n'en a aucun.
• Supposer que définir le timeout de connexion de curl borne aussi la durée totale du transfert.
• Supposer que httpx et requests partagent une même valeur par défaut valable pour tout l'écosystème Python ; ce n'est pas le cas.