Un téléchargement avec wget peut laisser un fichier qui ressemble à une archive, alors qu’il contient seulement une page HTML d’erreur. Si le serveur coupe la connexion, le fichier peut aussi rester incomplet. Voici une méthode simple pour reprendre le transfert, contrôler la réponse HTTP et éviter de traiter une page web comme un paquet Linux.
Préparer le téléchargement
Commencez par afficher les en-têtes du fichier distant. Cette étape permet de repérer une redirection, un type MIME inattendu ou une réponse HTTP en erreur avant d’écrire un gros fichier sur le disque.
wget --server-response --spider https://exemple.org/paquet.tar.gzDans la sortie, contrôlez notamment le code HTTP. Un téléchargement exploitable doit généralement finir sur une réponse 200 OK, ou sur une réponse partielle compatible avec la reprise. Si le serveur renvoie une page de connexion, un message d’erreur ou une redirection vers un autre domaine, corrigez l’URL avant de continuer.
Vous pouvez aussi demander à wget de choisir le nom du fichier avec -O. C’est utile quand l’URL se termine par une chaîne de paramètres :
wget -O paquet.tar.gz 'https://exemple.org/telechargement?id=42'Évitez toutefois d’utiliser -O pour reprendre un fichier existant. Pour une reprise fiable, laissez wget travailler sur le fichier local attendu.
Reprendre un fichier interrompu avec -c
Si le fichier local porte déjà le bon nom, l’option -c demande à wget de reprendre le transfert au point où il s’est arrêté :
wget -c https://exemple.org/paquet.tar.gzLe serveur doit accepter les requêtes avec l’en-tête Range. Si ce n’est pas le cas, wget peut recommencer depuis le début ou refuser la reprise. Vérifiez la taille locale avant de relancer :
ls -lh paquet.tar.gz
wget --server-response --spider https://exemple.org/paquet.tar.gzNe lancez pas -c sur un fichier dont vous ne connaissez pas l’origine. Un fichier HTML enregistré sous le nom paquet.tar.gz ne sera pas réparé par une reprise.
Éviter de garder une page HTML à la place de l’archive
Après le téléchargement, contrôlez le type réel du fichier et ses premiers octets :
file paquet.tar.gz
head -c 16 paquet.tar.gz | xxdUne archive gzip commence normalement par la signature 1f 8b. Pour une archive ZIP, la signature commence par 50 4b. Si file parle de document HTML, arrêtez-vous : le serveur a probablement renvoyé une erreur, une page d’authentification ou une réponse anti-bot.
Pour une archive tar compressée, vous pouvez ensuite demander une lecture de la table sans extraire les fichiers :
tar -tzf paquet.tar.gz >/dev/null && echo "Archive lisible"Vous retrouverez d’autres commandes utiles dans mon guide consacré à l’installation d’une archive tar.gz sous Linux. Cette vérification ne remplace pas un contrôle de l’URL : elle confirme seulement que le fichier récupéré a une structure exploitable.
Suivre les redirections et limiter le transfert
Les téléchargements publics passent souvent par une URL qui redirige vers un CDN. Utilisez --max-redirect pour éviter une chaîne anormalement longue :
wget --max-redirect=5 -c https://exemple.org/paquet.tar.gzSi vous devez contrôler les échanges plus précisément, le guide sur curl sous Linux pour tester une URL complète bien cette méthode. Pour un serveur lent ou une liaison fragile, --timeout et --tries permettent aussi de limiter les attentes et les tentatives :
wget -c --timeout=30 --tries=3 https://exemple.org/paquet.tar.gzVérifier l’intégrité avant d’installer
Quand l’éditeur fournit une somme SHA-256, comparez-la avant toute extraction ou installation :
sha256sum paquet.tar.gzLa valeur calculée doit correspondre exactement à celle publiée par le projet, idéalement sur son site officiel ou dans une signature séparée. Une taille correcte ne prouve pas qu’un téléchargement est intact.
Avec cette séquence, vous distinguez rapidement une vraie archive d’une page d’erreur et vous pouvez reprendre un téléchargement interrompu sans écraser inutilement le fichier local.
