Firefox et les gros téléchargements : régler le timeout pour les relancer
Sommaire
En bref
- Un utilisateur rapporte qu'augmenter network.http.response.timeout à 0 ou une valeur très élevée dans about:config rendrait les gros téléchargements reprenables et plus stables sous Firefox.
- Le problème affecterait Firefox 28 et les versions modernes, où le timeout de 300 secondes par défaut interfèrerait avec la gestion des téléchargements interrompus.
- La solution nécessite que le serveur supporte les téléchargements reprenables ; sans cela, aucun paramètre navigateur ne peut y remédier.
- Les commentaires remettent largement en question la validité de ce fix, avec plusieurs contributeurs citant le code source Firefox pour contester l'explication.
Ce que dit la source
L'auteur observe que Firefox 28 et versions récentes appliquent un timeout de 300 secondes (network.http.response.timeout) qui semble bloquer la reprise des gros téléchargements en cas d'interruption. Elle expose que modifier ce paramètre à 0 ou une valeur très grande améliore empiriquement la situation. Elle reconnaît ne pas comprendre le mécanisme exact et avoir testé sans consulter le code source de Firefox.
- Le timeout par défaut de 300 secondes affecterait les connexions de longue durée et la gestion des erreurs réseau
- Seuls les serveurs supportant HTTP Range Requests (reprise de téléchargement) bénéficient du changement
- La workaround manuelle existe : renommer le fichier .part et relancer le téléchargement pour forcer Firefox à le reprendre
- Alternatives documentées : wget -c, clients de téléchargement externes (aria2, JDownloader, IDM, NDM), ou via cURL et VPS pour les connexions instables
- Firefox affichait ce problème depuis au moins 2005 selon les rapports de bugs archivés
- Le comportement des .part files et les retry implicites restent mal documentés dans le code public
Dans les commentaires
Débat très partagé : la thèse de l'auteur est contredite par au moins un contributeur qui cite le searchfox de Mozilla pour affirmer que network.http.response.timeout est inutilisé quand TCP-KeepAlive est activé (défaut). Plusieurs utilisateurs rapportent avoir jamais observé de problème de reprise, d'autres confirment les blocages en cas de lien one-time. Consensus sur le manque de précision de l'explication originale.
- Un commentateur cite deux liens vers le code Firefox (searchfox) et un bug report officiel pour contester directement l'analyse : le timeout ne s'activerait qu'avant le premier byte, et TCP-KeepAlive le désactiverait de toute façon
- Plusieurs utilisateurs rapportent des expériences opposées : jamais de problème observé sur leurs installations, ou problème limité aux URLs one-time (qui retournent 400 Error)
- L'auteur reconnaît ne pas avoir consulté le code source de Firefox ; plusieurs contributeurs soulignent cette limite et demandent des détails reproductibles
- Divergence sur la fréquence du problème : certains n'ont jamais rencontré d'instabilité de reprise, d'autres évitent les navigateurs pour les gros fichiers depuis des années
- Une objection porte sur la généralisation : les commentateurs citent des navigateurs mineurs (avec binaires compilés statiques < 2MB) où la reprise semble fiable, contestant l'idée que 'tous les navigateurs' souffrent du même défaut
Alternatives citées : aria2, wget, JDownloader 2, IDM (Internet Download Manager), NDM (Ninja Download Manager), tnftp, curl + VPS, extensions XUL historiques (supprimées avec les versions récentes)
Notre lecture
Intéressant mais à valider avant action. La syntaxe du paramètre est réelle, mais l'explication causale fournie par l'auteur est probablement inexacte selon au moins un commentateur qui pointe le code source. Le problème de stabilité des reprises sur les gros fichiers existe bel et bien depuis longtemps (rapports de bugs Mozilla datant de 2005), mais il n'affecte pas tous les utilisateurs équitablement. Pour les DSI ou équipes ayant des besoins fiables de téléchargement de gros volumes, les solutions éprouvées restent : wget, aria2, ou des gestionnaires dédiés (JDownloader, IDM). Le tweak Firefox peut valoir la peine d'être testé en environnement de test si ce problème se pose réellement, mais sans garantie de succès documenté.