wget(1)

L'outil de téléchargement réseau non interactif. · man1 · Français

WGET(1) GNU Wget WGET(1)

Wget - L'outil de téléchargement réseau non interactif.

wget [option]... [URL]...

GNU Wget est un utilitaire libre pour le téléchargement non-interactif de fichiers sur le Web. Il prend en charge les protocoles HTTP, HTTPS, et FTP, ainsi que le téléchargement au travers des mandataires HTTP.

Wget est non interactif, c'est-à-dire qu'il peut travailler en arrière-plan, sans intervention de l'utilisateur. Cela permet de lancer un téléchargement et de se déconnecter du système, laissant wget finir le travail. En revanche, la plupart des navigateurs Web requièrent la présence constante de l'utilisateur, ce qui est particulièrement pénible lorsqu'il y a beaucoup de données à transférer.

wget peut suivre les liens des pages HTML et XHTML, et CSS, pour créer des copies locales de sites web distants, en récréant complètement la structure du site original. Cela est parfois désigné sous le nom de « téléchargement récursif ». En faisant cela, wget respecte le standard d'exclusion de robots (/robots.txt). wget peut aussi être chargé de convertir les liens dans les fichiers téléchargés pour pointer sur des fichiers locaux, pour une consultation hors-ligne.

wget a été conçu pour être robuste en dépit des connexions réseaux lentes ou instables ; si un téléchargement échoue suite à un problème réseau, il réessayera jusqu'à ce que l'intégralité du fichier soit récupérée. Si le serveur gère la reprise, il lui demandera de reprendre là où le téléchargement s'est interrompu.

Comme wget utilise GNU getopt pour traiter les arguments de la ligne de commande, chaque option a une forme longue en plus de la forme courte. Les options longues sont plus pratiques à retenir, mais prennent du temps à taper. Vous êtes libre de mélanger différentes formes d'options, ou d'indiquer les options après les arguments de la ligne de commande. Ainsi, vous pouvez écrire :

 wget -r --tries=10 http://fly.srk.fer.hr/ -o log

L'espace entre l'option acceptant un argument et l'argument peut être omise. Vous pouvez écrire -olog au lieu de -o log.

Vous pouvez mettre ensemble plusieurs options ne nécessitant pas d'arguments, comme :

 wget -drc <URL>

Cela est absolument équivalent à :

 wget -d -r -c <URL>

Comme les options peuvent être indiquées après les arguments, vous pouvez les terminer avec --. Ainsi, ce qui suit va essayer de télécharger URL -x, en signalant l'échec à log :

 wget -o log -- -x

Les options qui acceptent des listes séparées par des virgules respectent toutes la convention selon laquelle spécifier une liste vide efface sa valeur. Cela peut être utile pour nettoyer les réglages de .wgetrc. Par exemple, si .wgetrc indique "exclude_directories" à /cgi-bin, l'exemple suivant le réinitialisera d'abord, puis lui indiquera d'exclure /~nobody et /~somebody. Vous pouvez aussi effacer les listes dans .wgetrc.

 wget -X "" -X /~nobody,/~somebody

La majorité des options qui n'acceptent pas d'arguments sont des options de type booléen, ainsi nommées car leur état peut être capturé avec une variable oui-ou-non (« booléenne »). Par exemple, --follow-ftp indique à wget de suivre les liens FTP de fichiers HTML et, d'un autre coté, --no-glob lui dit de ne pas effectuer le « globbing » de fichiers sur les URL FTP. Une option booléenne peut être affirmative ou négative (commençant par --no). Toutes ces options partagent plusieurs propriétés.

Sauf indication contraire, il est supposé que le comportement par défaut soit l'opposé de ce que l'option réalise. Par exemple, l'existence documentée de --follow-ftp suppose que le comportement par défaut est de ne pas suivre les liens FTP des pages HTML.

Les options affirmatives peuvent être niées en antéposant le --no au nom de l'option ; les options négatives peuvent être niées en ommettant le préfixe --no. Cela peut sembler superflu : si le comportement par défaut d'une option affirmative est de ne pas faire quelque chose, alors pourquoi lui fournir un moyen pour le faire ? Mais le fichier de démarrage peut en fait changer le comportement par défaut. Par exemple, l'utilisation de "follow_ftp = on" dans .wgetrc fait suivre les liens FTP à wget par défaut, et l'utilisation de --no-follow-ftp est la seule manière de restaurer le comportement par défaut d'origine depuis la ligne de commande.

Afficher la version de wget.
Afficher un message d'aide décrivant toutes les options en ligne de commande de wget.
Passer en arrière-plan aussitôt après le démarrage. Si aucun fichier de sortie n'est indiqué avec -o, la sortie est redirigée dans wget-log.
Exécuter la commande comme faisant partie de .wgetrc. Une commande invoquée ainsi sera exécutée après les commandes dans .wgetrc, par conséquent prévalant sur elles. Si vous avez besoin d'indiquer plus d'une commande dans wgetrc, utilisez plusieurs instances de -e.

Enregistrer tous les messages dans fichier_journal. Les messages sont habituellement affichés sur la sortie d'erreur standard.
Ajouter dans fichier_journal. Cela est équivalent à -o, mais ajoute au fichier_journal au lieu d'écraser l'ancien fichier fichier_journal. Si fichier_journal n'existe pas, un nouveau fichier est créé.
Activer la sortie de débogage, c'est-à-dire des informations importantes pour les développeurs de wget si quelque chose ne fonctionne pas correctement. Votre administrateur système peut avoir choisi de compiler wget sans l'option de débogage, dans ce cas -d ne fonctionnera pas. Remarquez que compiler avec l'option de débogage est toujours sûr, wget compilé sans la prise en charge du débogage n'affichera pas d'informations de débogage, à moins de le demander avec -d.
Désactiver la sortie de wget.
Activer le mode verbeux, avec toutes les données disponibles. Ce mode est activé par défaut.
Désactiver le mode verbeux sans être totalement silencieux (utilisez -q pour cela), signifiant que les messages d'erreur et les informations de base seront encore affichés.
Bande passante de sortie comme type. La seule valeur acceptée est bits.
Lire les URL depuis un fichier local ou externe. Si - est indiqué comme fichier, les URL sont lues depuis l'entrée standard. (Utilisez ./- pour lire à partir d'un fichier nommé -).

Si cette fonction est utilisée, aucune URL n'a besoin d'être présente sur la ligne de commande. S'il y a des URL à la fois sur la ligne de commande et dans le fichier d'entrée, celles sur la ligne de commande seront les premières à être extraites. Si --force-html n'est pas indiqué, alors le fichier devrait consister en une suite d'URL, une par ligne.

Cependant, si vous indiquez --force-html, le document sera considéré comme html. Dans ce cas, vous pourriez avoir des problèmes avec les liens relatifs, que vous pouvez résoudre en ajoutant « <base href=url> » aux documents ou en indiquant --base=url sur la ligne de commande.

Si le fichier est externe, le document sera automatiquement traité comme du html si le type de contenu correspond à text/html. Par ailleurs, l'emplacement du fichier sera implicitement utilisé comme href de base si aucun n'est indiqué.

Télécharger les fichiers couverts par le fichier Metalink local. Metalink versions 3 et 4 sont pris en charge.
Garder les fichiers Metalink téléchargés avec un mauvais hachage. Cela ajoute .badhash aux noms de fichiers Metalink qui sont incohérents avec la somme de contrôle, sans écraser les fichiers existants.
Émettre une requête HTTP HEAD au lieu de GET et extraire les métadonnées Metalink des en-têtes de réponse. Ensuite, il passe au téléchargement de Metalink. Si aucune métadonnée Metalink n'est trouvée, il revient au téléchargement ordinaire HTTP. Cela permet le téléchargement et le traitement des fichiers Content-Type: application/metalink4+xml.
Définir le NUMÉRO. ordinal de la méta-url application/metalink4+xml de Metalink de 1 au nombre total de "application/metalink4+xml" disponibles. Spécifier 0 ou inf pour choisir la première qui est bonne. Les méta-url, telles que celles d'un --metalink-over-http, peuvent avoir été triées par une valeur de clé de priorité ; gardez cela à l'esprit pour choisir le bon NUMÉRO.
Définir l'emplacement préféré pour les ressources Metalink. Cela est utile si plusieurs ressources ayant la même priorité sont disponibles.
Activer l'utilisation des attributs étendus du système de fichiers pour sauvegarder la valeur l'URL d'origine et la valeur de l'en-tête référent HTTP si elle est utilisée.

Gardez à l'esprit que les URL pourraient contenir des informations privées telles que des jetons d'accès ou des identifiants.

Lorsque l'entrée lue est un fichier, le forcer à être traité comme un fichier HTML. Cela vous permet de retrouver des liens relatifs de fichiers HTML sur votre disque local, en ajoutant <base href="url"> à HTML, ou en utilisant l'option de la ligne de commande --base.
Résoudre les liens relatifs en utilisant URL comme point de référence lors de la lecture de liens d'un fichier HTML spécifié à l'aide de l'option -i/--input-file (conjointement avec --force-html, ou lorsque le fichier d'entrée a été récupéré à distance depuis un serveur le décrivant comme HTML). Cela est équivalent à la présence d'un drapeau "BASE" dans le fichier en entrée, avec URL comme valeur de l'attribut "href".

Par exemple, si vous indiquez http://machin/truc/a.html comme URL, et que wget lit ../bidule/b.html sur le fichier d'entrée, il sera résolu en http://machin/bidule/b.html.

Indiquer l'emplacement du fichier d'initialisation que vous voulez utiliser à la place de celui ou ceux par défaut. Utiliser --no-config pour désactiver la lecture des fichiers de configuration. Si à la fois --config et --no-config sont donnés, --no-config est ignoré.
Enregistrer tous les rejets d'URL dans fichier_journal avec des valeurs séparées par des virgules. Les valeurs incluent la raison du rejet, l'URL et l'URL parent dans lequel il a été trouvé.

Lors des connexions TCP/IP client, l'attacher à ADDRESS sur la machine locale. ADDRESS peut être indiquée comme un nom d'hôte ou une adresse IP. Cette option peut être utile si votre machine est attachée à plusieurs IP.
[seulement avec libcares] Cette adresse surcharge la route pour les requêtes DNS. Si vous avez besoin de contourner les réglages standard de /etc/resolv.conf, cette option avec --dns-servers est votre amie.ADDRESS doit être spécifiée comme une adresse soit IPV4, soit IPV6. wget doit être construit avec libcares pour que cette option soit disponible.
[seulement avec libcares] Les adresses données écrasent les adresses du serveur de noms standard, par exemple comme configuré dans /etc/resolv.conf. Les ADDRESSES doivent être spécifiées en adresses IPV4 ou IPV6 séparées par des virgules. wget a besoin d'être construit avec libcares pour que cette option soit disponible.
Définir le nombre d'essais à nombre. Spécifier 0 ou inf pour réessayer indéfiniment. Par défaut, la commande réessaie 20 fois, à l'exception des erreurs fatales comme "connection refused" ou "not found" (404), qui ne sont pas réessayées.
Les documents ne seront pas écrits dans les fichiers appropriés, mais seront tous concaténés et écrits dans fichier. Si - est utilisé comme fichier, les documents seront écrits sur la sortie standard, désactivant la conversion de liens. (Utilisez ./- pour écrire dans un fichier littéralement appelé -.)

L'utilisation de -O ne signifie pas simplement « utiliser le nom fichier au lieu de celui dans l'URL ». Cela est plutôt similaire à une redirection d'interpréteur : wget -O fichier http://truc est destiné à fonctionner comme wget -O - http://truc > fichier . fichier sera tronqué immédiatement et tout le contenu téléchargé sera écrit là.

Pour cette raison, -N (pour le contrôle d'horodatage) n'est pas pris en charge en combinaison avec -O : dans la mesure où fichier est tout le temps nouvellement créé, il aura toujours un horodatage très récent. Un avertissement sera affiché si la combinaison des deux est utilisée.

De même, l'utilisation de -r ou -p avec -O peut ne pas fonctionner comme vous voudriez : wget ne téléchargera pas seulement le premier fichier dans fichier et ensuite le reste dans leurs noms courants : tout le contenu téléchargé sera placé dans fichier. Cela a été désactivé dans la version 1.11, mais a été réimplanté (avec un avertissement) dans la version 1.11.2, puisqu'il y a des cas où ce fonctionnement peut avoir une certaine utilité.

Une combinaison avec -nc n'est acceptée que si le fichier donné en sortie n'existe pas.

Remarquez qu'une combinaison avec -k n'est permise que lors du téléchargement d'un seul document, car dans ce cas il convertira seulement toutes les URl relatives en URL externes ; -k n'a pas de sens pour des URl multiples lorsqu'elles sont toutes téléchargées dans un seul fichier ; -k ne peut être utilisé que lorsque la sortie est un fichier normal.

Si un fichier est téléchargé plus d'une fois dans le même répertoire, le comportement de wget dépend de quelques options, incluant -nc. Dans certains cas, le fichier local sera corrompu ou écrasé après un téléchargement répété. Dans d'autres cas, il sera préservé.

Lorsque wget est lancé sans -N, -nc, -r ou -p, le téléchargement du même fichier dans le même répertoire préservera la copie d'origine de fichier et la seconde copie sera nommée fichier.1. Si ce fichier est à nouveau téléchargé, la troisième copie sera nommée fichier.2, et ainsi de suite. (Cela est aussi le comportement avec -nd, même si -r ou -p sont effectifs.) Lorsque -nc est spécifié, ce comportement est supprimé, et wget refusera de télécharger de nouvelles copies de fichier. Par conséquent, « no-clobber » est en fait un terme mal choisi dans ce mode -- ce n'est pas la corruption qui est empêchée (comme les suffixes numériques empêchent déjà la corruption), mais plutôt l'enregistrement de plusieurs versions qui est empêché.

Lorsque wget est lancé avec -r ou -p, mais sans -N, -nd ou -nc, télécharger à nouveau un fichier résultera en ce que la nouvelle copie écrasera simplement la précédente. Ajouter -nc empêchera ce comportement, provoquant plutôt la préservation de la version originale et faisant que les copies plus récentes sur le serveur seront ignorées.

Lors du lancement de wget avec -N, avec ou sans -r ou -p, la décision de télécharger ou non une copie plus récente d'un fichier dépend de l'horodatage local et distant et de la taille du fichier. -nc peut ne pas être spécifié au même moment que -N.

Une combinaison avec -O/--output-document n'est acceptée que si le fichier donné en sortie n'existe pas.

Notez que lorsque -nc est spécifié, les fichiers avec les suffixes .html ou .htm seront chargés depuis le disque local et analysés comme s'ils avaient été récupérés sur le Web.

Avant d'écrire ou d'écraser un fichier, faire une sauvegarde du fichier existant en ajoutant un suffixe .1 (_1 sur VMS) au nom de fichier. De tels fichiers de sauvegarde sont numérotés .2, .3, et ainsi de suite, jusqu'à sauvegardes (et perdus après).
Ne pas essayer d'obtenir des identifiants du fichier .netrc. Par défaut les identifiants sont recherchés dans le fichier .netrc dans le cas où aucun n'ait été passé sur la ligne de commande et qu'une authentification serait nécessaire.
Continuer à récupérer un fichier partiellement téléchargé. Cela est utile lorsque vous voulez finir un téléchargement commencé lors d'une précédente instance de wget, ou par un autre programme. Par exemple : 
 wget -c ftp://sunsite.doc.ic.ac.uk/ls-lR.Z

S'il y a un fichier nommé ls-lR.Z dans le répertoire actuel, wget supposera qu'il s'agit de la première partie du fichier distant, et demandera au serveur de poursuivre la récupération à partir d'un décalage égal à la longueur du fichier local.

Remarquez que vous n'avez pas besoin d'indiquer cette option si vous voulez simplement que l'invocation actuelle de wget réessaie de télécharger un fichier si la connexion est perdue en cours de route. C'est le comportement par défaut. -c n'affecte que la reprise des téléchargements commencés avant cette invocation de wget, et dont les fichiers locaux sont toujours en attente.

Sans -c, l'exemple précédent devrait juste télécharger le fichier distant dans ls-lR.Z.1, laissant seul le fichier tronqué ls-lR.Z.

Si vous utilisez -c sur un fichier non vide, et que le serveur ne prend pas en charge la reprise du téléchargement, wget relancera le téléchargement depuis le début et écrasera entièrement le fichier existant.

À partir de Wget 1.7, si vous utilisez -c sur un fichier ayant une taille égale à celui sur le serveur, wget refusera de télécharger le fichier et affichera un message explicatif. La même chose arrive lorsque le fichier est plus petit sur le serveur que celui en local (probablement parce qu'il a été modifié depuis votre dernière tentative de téléchargement) -- parce que « continuing » n'est pas assez explicite, aucun téléchargement n'est lancé.

D'un autre coté, en utilisant -c, tout fichier qui est plus gros sur le serveur qu'en local sera considéré comme un téléchargement incomplet et seulement (longueur(distante) - longueur(locale)) octets seront téléchargés et ajoutés à la fin du fichier local. Ce comportement est appréciable dans quelques cas. Par exemple, vous pouvez utiliser wget -c pour télécharger uniquement la nouvelle partie qui a été ajoutée à une collection de données ou à un fichier journal.

En tout cas, si le fichier est plus gros sur le serveur parce qu'il a été modifié, contrairement à juste ajouté, vous vous retrouverez avec un fichier brouillé. wget n'a pas la possibilité de vérifier que le fichier local est réellement un début valable du fichier distant. Vous devez être particulièrement attentif à cela lors de l'utilisation de -c en combinaison avec -r, vu que tout fichier sera considéré comme un « téléchargement incomplet » potentiel.

Un autre cas où vous obtiendrez un fichier brouillé si vous essayez d'utiliser -c, est celui où vous avez un mandataire HTTP bancal qui insère une chaîne "transfer interrupted") dans le fichier local. Dans le futur, une option "rollback" (retour à l'état précédent) devrait être ajoutée pour gérer ce cas de figure.

Prenez en compte que -c ne fonctionne qu'avec les serveurs FTP et les serveurs HTTP qui prennent en charge l'en-tête "Range".

Commencer le téléchargement à la position d'OFFSET par rapport à zéro. Le décalage doit être exprimé en octets, kilooctets avec le suffixe k ou mégaoctets avec le suffixe m, etc.

--start-pos a la priorité sur --continue. Lorsque --start-pos et --continue sont toute deux indiquées, wget émettra un avertissement et procèdera comme si --continue était absent.

La prise en charge du serveur pour la poursuite du téléchargement est nécessaire, sinon --start-pos ne pourra pas aider. Voir -c pour les détails.

Sélectionnez le type d'indicateur de progression que vous désirez utiliser. Les indicateurs classiques sont « dot » (point) et « bar » (trait).

L'indicateur "bar" est utilisé par défaut. Il dessine un graphique de barre de progression ASCII (comme un affichage « thermomètre ») indiquant l'état de la récupération. Si la sortie n'est pas une console TTY, la barre de progression « dot » sera utilisée par défaut.

Utilisez --progress=dot pour passer à l'affichage "pointillé"). Il retrace la récupération en affichant des points sur l'écran, chaque point représentant une quantité fixe de données téléchargées.

Le type de progression peut aussi prendre un ou plusieurs paramètres. Les paramètres varient suivant le type sélectionné. Les paramètres sont passés au type en les ajoutant au type, séparés par un deux-points ( : ) comme ceci : --progress=type:paramètre1:paramètre2.

Lorsque vous utilisez la représentation de la récupération par points, vous pouvez définir le style en spécifiant le type comme dot:style. Les différents styles assignent différents rôles à un point. Avec le style « default » chaque point représente 1Ko, il y a dix points par grappe et 50 points sur une ligne. Le style « binary » a plus une orientation du genre « ordinateur » : points de 8Ko, 16 points par grappe et 48 points par ligne (ce qui fait des lignes de 384Ko). Le style « mega » est adapté au téléchargement de gros fichiers : chaque point représentant 64Ko de récupération, il y a huit points dans une grappe, et 48 points sur chaque ligne (chaque ligne contenant 3Mo). Si « mega » n'est pas suffisant, alors vous pouvez utiliser le style « giga » -- chaque point représente 1 Mo récupérés, il y a huit points par grappe, et 32 points par ligne (donc chaque ligne contient 32Mo).

Avec --progress=bar, il y a actuellement deux paramètres possibles, force et noscroll.

Lorsque la sortie n'est pas une console TTY, la barre de progression retombe toujours sur "dot", même si --progress=bar a été passé à wget lors de l'invocation. Ce comportement peut être outrepassé et la sortie "bar" forcée avec le paramètre "force" comme --progress=bar:force.

Par défaut, la barre de progression du style bar fait défiler le nom du fichier de gauche à droite pour le fichier en cours de téléchargement si le nom du fichier dépasse la longueur maximale allouée à son affichage. Dans certains cas, comme avec --progress=bar:force, il peut ne pas y avoir de défilement du nom de fichier dans la barre de progression. En passant le paramètre "noscroll", wget peut être forcé à afficher la plus grande partie possible du nom de fichier sans le faire défiler.

Remarquez que vous pouvez indiquer le style par défaut en utilisant la commande "progress" dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande. Par exemple, pour forcer la barre de sortie à ne pas défiler, utilisez --progress=bar:force:noscroll.

Forcer wget à afficher la barre de progression quelque soit le niveau de détail.

Par défaut, wget affiche seulement la barre de progression en mode détaillé. Il est possible de vouloir que wget affiche la barre de progression en accord avec un autre mode de détail comme --no-verbose ou --quiet. Cela peut être désirable lors de l'invocation de wget pour télécharger plusieurs petits et/ou grands fichiers. Dans un tel cas, wget pourrait simplement être invoqué avec ce paramètre pour avoir une sortie plus propre sur l'écran.

Cette option forcera également la barre de progression à être affichée dans stderr lorsqu'elle est utilisée avec l'option --output-file.

Activer l'horodatage.
Ne pas envoyer d'en-tête If-Modified-Since en mode -N. Envoyer d'abord une réponse HEAD à la place. Cela n'est effectif qu'en mode -N.
Ne pas régler l'horodatage du fichier local sur celui du serveur.

Par défaut, lorsqu'un fichier est téléchargé, son horodatage est réglé pour correspondre à celui du fichier distant. Cela permet l'utilisation de --timestamping sur les invocations suivantes de wget. Cependant, il est parfois nécessaire de baser l'horodatage du fichier local sur celui de son téléchargement ; l'option --no-use-server-timestamps a été fournie dans ce but.

Afficher les en-têtes envoyés par les serveurs HTTP et les réponses envoyées par les serveurs FTP.
Lorsqu'il est invoqué avec cette option, wget se comportera comme un robot d'indexation, il ne téléchargera pas les pages, il vérifiera simplement leur présence. Par exemple, vous pouvez utiliser wget pour vérifier vos marque-pages : 
 wget --spider --force-html -i marque-pages.html

Cette caractéristique nécessite encore quelques travaux pour se rapprocher des fonctionnalités de véritables robots d'indexation.

Définir le délai d'attente du réseau à secondes. Cela est équivalent à spécifier --dns-timeout, --connect-timeout et --read-timeout, tous en même temps.

Lorsqu'il interagit avec le réseau, wget peut vérifier le délai d'attente et annuler l'opération si cela dure trop. Cela permet d'éviter les anomalies telles que les lectures suspendues et les connexions infinies. Le seul délai d'attente activé par défaut est un délai d'attente de lecture de 900 secondes (15 min). Définir un délai d'attente à 0 désactive l'ensemble. À moins de savoir ce que vous faites, il vaut mieux ne pas changer les réglages du délai d'attente par défaut.

Toutes les options liées au délai d'attente acceptent les valeurs décimales, ainsi que les valeurs en dixième de seconde. Par exemple, 0.1 seconde est un choix classique (bien que peu judicieux) du délai d'attente. Les temps d'attente en dixièmes de seconde sont utiles pour la vérification des temps de réponse du serveur ou pour tester la latence du réseau.

Définir le délai de consultation de DNS à secondes. Les recherches DNS qui ne sont pas terminées dans le délai spécifié échouent. Par défaut, il n'y a pas de délai sur les recherches DNS, autre que celui implémenté par les bibliothèques du système.
Définir le délai de connexion à secondes. Les connexions TCP qui mettent trop longtemps à s'établir seront annulées. Il n'y a pas de délai de connexion par défaut, autre que celui qui est implémenté par les bibliothèques du système.
Définir le délai de lecture (et d'écriture) à secondes. Le « temps » de ce délai correspond à idle time : si, à quelque moment du téléchargement, aucune donnée n'est reçue durant plus que le nombre spécifié de secondes, la lecture échoue et le téléchargement est recommencé. Cette option n'influe pas directement sur la durée totale du téléchargement.

Bien sûr, le serveur distant peut choisir de terminer la connexion plus tôt que requis par cette option. Le délai de lecture est de 900 secondes (15 min) par défaut.

Limiter la vitesse de téléchargement à quantité octets par seconde. Cette quantité doit être exprimée en octets, kilooctets (avec le suffixe k), ou mégaoctets (avec le suffixe m). Par exemple, --limit-rate=20K limitera le débit de récupération à 20 ko/s. Cela est utile lorsque, pour une raison quelconque, vous ne voulez pas que wget consomme toute la bande passante disponible.

Cette option autorise l'usage de nombres décimaux, habituellement en conjonction avec des suffixes de puissance ; par exemple, --limit-rate=2.5k est une valeur classique.

Remarquez que wget implémente la limitation en dormant pendant la durée appropriée après une réception depuis le réseau qui a pris moins de temps que spécifié par le débit. Finalement cela peut causer le ralentissement du tranfert TCP jusqu'à approximativement le débit spécifié. Cependant, il se peut que cela prenne un peu de temps avant de se stabiliser ; ne soyez pas surpris si cette limite n'est pas vraiment respectée lors du transfert de très petits fichiers.

Attendre le nombre de secondes spécifié entre deux récupérations. L'utilisation de cette option est encouragée, car elle allège le travail du serveur en diminuant la fréquence des requêtes. Au lieu de secondes, le temps peut être indiqué en minutes en utilisant le suffixe "m", en heures avec le suffixe "h", ou en jours avec le suffixe "d".

L'indication d'une grande valeur pour cette option est pratique si le réseau ou l'hôte de destination est éteint, ainsi wget peut attendre assez longtemps pour raisonnablement espérer que l'erreur réseau soit réparée d'ici le prochain essai. L'intervalle de temps d'attente indiqué par cette fonction est influencé par "--random-wait" qui surveille.

Si vous ne voulez pas que wget attende entre chaque récupération, mais seulement entre les nouvelles tentatives suite à des échecs de téléchargement, vous pouvez utiliser cette option. wget utilisera linear backoff, en attendant une seconde après le premier échec sur un fichier donné, puis deux secondes après le second échec sur ce fichier, jusqu'au nombre maximal de secondes indiqué.

Par défaut, wget prendra une valeur de dix secondes.

Certains sites web peuvent effectuer une analyse des journaux pour identifier les programmes d'extraction tels que wget en recherchant des similitudes statistiquement significatives dans le délai entre les requêtes. Cette option fait varier entre 0,5 et 1,5 * secondes d'attente, où secondes d'attente est indiquée par l'usage de l'option --wait, pour masquer la présence de wget à partir de ce type d'analyse.

Un article est paru en 2001 dans une publication consacrée au développement sur une plate-forme populaire grand public qui fournissait un code permettant d'effectuer cette analyse à la volée. Son auteur a suggéré un blocage au niveau des adresses de classe C pour s'assurer que les programmes d'extraction automatique soient bloqués malgré le changement des adresses fournies par le DHCP.

L'option --random-wait a été inspirée par cette recommandation peu judicieuse qui consiste à bloquer l'accès à un site web à de nombreux utilisateurs non concernés en raison des actions d'un seul.

Ne pas utiliser de mandataire, même si la variable d'environnement appropriée *_proxy est définie.
Indiquer le quota de téléchargement pour l'extraction automatique. Cette valeur peut être indiquée en octets (par défaut), kilooctets (avec le suffixe k) ou mégaoctets (avec le suffixe m).

Remarquez que le quota n'affectera jamais le téléchargement d'un seul fichier. Donc si vous indiquez wget -Q10k https://example.com/ls-lR.gz, tout le fichier ls-lR.gz sera téléchargé. C'est la même chose lorsque plusieurs URL sont indiquées sur la ligne de commande. Le quota n'est seulement vérifié qu'à la fin de chaque fichier téléchargé, donc il ne provoquera jamais le téléchargement partiel d'un fichier. Ainsi vous pouvez tranquillement taper wget -Q2m -i sites, le téléchargement s'arrêtera après que le fichier qui dépasse le quota a été complètement téléchargé.

Définir le quota à 0 ou à inf retire la limite du quota de téléchargement.

Désactiver la mise en cache des recherches de DNS. Normalement, wget se souvient des adresses IP qu'il a recherché auprès de DNS afin de ne pas avoir à contacter de manière répétée le serveur DNS pour le même (généralement petit) ensemble d'hôtes utilisé pour la récupération. Ce cache n'existe qu'en mémoire ; un nouveau lancement de wget recontactera encore le DNS.

Cela dit, il a été rapporté que dans quelques situations, il n'est pas désirable de mettre en cache les noms d'hôtes, même pour la durée d'une application brève et rapide comme wget. Avec cette option, wget effectue une nouvelle recherche DNS (plus précisément, un nouvel appel à "gethostbyname" ou "getaddrinfo") à chaque nouvelle connexion. Veuillez prendre en compte que cette option n'affectera pas la mise en cache qui pourrait être effectuée par la bibliothèque de résolution ou par une couche de mise en cache externe, telle que NSCD.

Si vous ne comprenez pas exactement ce que fait cette option, vous n'en avez probablement pas besoin.

Modifier les caractères trouvés dans les URL distants qui doivent être protégés lors de la génération des noms de fichiers locaux. Les caractères qui sont restreints par cette option sont protégés, c'est-à-dire remplacés par %HH, où HH est le nombre hexadécimal qui correspond au caractère restreint. Cette option peut aussi être utilisée pour forcer les caractères alphabétiques à être soit en minuscules, soit en capitales.

Par défaut, wget protège les caractères qui ne sont pas valables ou sûrs dans les noms de fichiers pour votre système d'exploitation, ainsi que pour les caractères de contrôle habituellement impossibles à afficher. Cette option est utile pour changer ce comportement par défaut, peut être parce que vous téléchargez dans une partition non native, ou parce que vous voulez désactiver la protection des caractères de contrôle, ou parce que vous voulez restreindre encore plus de caractères à ceux de la plage de valeurs ASCII.

Les modes sont un ensemble de valeurs textuelles séparées par des virgules. Les valeurs acceptées sont unix, windows, nocontrol, ascii, lowercase et uppercase. Les valeurs unix et windows sont mutuellement exclusives (l'une écrasera l'autre), de même pour lowercase et uppercase. Ces deux dernières sont des cas spéciaux, car elles ne changent pas l'ensemble des caractères qui devraient être protégés, mais plutôt forcent les chemins de fichier local à être converti soit en minuscules ou en capitales.

Lorsque "unix" est indiqué, wget protège le caractère / et les caractères de contrôle dans les plages de 0 à 31 et de 128 à 159. C'est le comportement par défaut pour les systèmes d'exploitation de type Unix.

Lorsque "windows" est indiqué, wget protège les caractères \, |, /, :, ?, ", *, <, >, et les caractères contrôle dans les plages de 0 à 31 et de 128 à 159. En plus de cela, wget en mode Windows utilise + au lieu de : pour séparer l'hôte et le port dans les noms de fichiers locaux, et utilise @ au lieu de ? pour séparer la partie requête du nom de fichier du reste. Par conséquent, une URL qui aurait été sauvegardée en www.xemacs.org:4300/search.pl?input=blabla en mode Unix pourrait l'être en www.xemacs.org+4300/search.pl@input=blabla en mode Windows. C'est le mode par défaut sur Windows.

Si vous indiquez nocontrol, alors la protection des caractères de contrôle est aussi désactivée. Cette option est utile lorsque vous téléchargez des URL avec des noms contenant des caractères UTF-8 sur un système qui peut sauvegarder et afficher les noms de fichiers en UTF-8 (certaines valeurs d'octets possibles utilisées dans les séquences d'octets UTF-8 tombent dans la plage de valeurs désignée par wget comme "contrôles").

Le mode ascii est utilisé pour spécifier que tous les octets dont la valeur est en dehors de la plage de caractères ASCII, (c'est-à-dire supérieure à 127) doivent être protégés. Cela est utile lors de la sauvegarde des noms de fichiers dont l'encodage ne correspond pas à celui utilisé en local.

-4
-6
Forcer la connexion vers les adresses IPv4 ou IPv6. Avec --inet4-only ou -4, wget ne se connectera qu'à des hôtes IPv4, ignorant les enregistrements AAAA du DNS, et refusant de se connecter aux adresses IPv6 indiquées dans les URL. Au contraire, avec --inet6-only ou -6, wget ne se connectera qu'aux hôtes IPv6 et ignorera les enregistrements A et les adresses IPv4.

Aucune de ces options ne devrait être normalement nécessaire. Par défaut, un wget prenant en charge IPv6 utilisera la famille d'adresses spécifiée par l'enregistrement DNS de l'hôte. Si le DNS répond avec à la fois des adresses IPv4 et IPv6, wget les essaiera dans l'ordre jusqu'à ce qu'il en trouve une pour se connecter. Consultez aussi l'option "--prefer-family" décrite ci-dessous.

Ces options peuvent être utilisées pour forcer délibérément l'usage des familles d'adresses IPv4 ou IPv6 sur les systèmes avec les deux familles, habituellement pour aider au débogage ou s'occuper d'une configuration réseau défaillante. Seulement l'une des options --inet6-only et --inet4-only peut être indiquée au même moment. Aucune option n'est disponible si wget a été compilé sans la prise en charge de IPv6.

Lors d'un choix avec plusieurs adresses, se connecter d'abord aux adresses indiquées dans la famille d'adresses. Par défaut, l'ordre des adresses renvoyé par DNS est utilisé sans changement.

Cela permet d'éviter les erreurs et les tentatives de connexion intempestives lors de l'accès à des hôtes dont l'adresse est à la fois IPv6 et IPv4 à partir de réseaux IPv4. Par exemple, www.kame.net se résout en 2001:200:0:8002:203:47ff:fea5:3085 et en 203.178.141.194. Lorsque la famille souhaitée est "IPv4", l'adresse IPv4 sera utilisée en premier ; lorsque la famille souhaitée est "IPv6", l'adresse IPv6 sera utilisée en premier ; si la valeur indiquée est "none", l'ordre des adresses renvoyé par DNS est utilisé sans changement.

Contrairement à -4 et -6, cette action n'empêche pas l'accès à une quelconque famille d'adresse, elle change juste l'ordre dans lequel on accède aux adresses. Remarquez aussi que le réordonnancement effectué par cette option est stable : il n'affecte pas l'ordre des adresses de la même famille. C'est-à-dire que l'ordre relatif de toutes les adresses IPv4 et de toutes les adresses IPv6 reste intact dans tous les cas.

Considérer "connection refused" comme une erreur passagère et réessayer. Normalement, wget abandonne une URL lorsqu'il ne parvient pas à se connecter au site, car l'échec de la connexion est considéré comme un signe que le serveur ne fonctionne pas du tout et que de nouvelles tentatives ne seraient d'aucune utilité. Cette option est destinée à la mise en miroir de sites peu fiables dont les serveurs ont tendance à disparaître pendant de courtes périodes.
Indiquer le nom d'utilisateur utilisateur et le mot de passe mot_de_passe pour la récupération des fichiers à la fois FTP et HTTP. Ces paramètres peuvent être écrasés par l'utilisation des options --ftp-user et --ftp-password pour les connexions FTP et les options --http-user et --http-password pour les connexions HTTP.
Demander un mot de passe pour chaque connexion établie. Ne peut pas être indiqué quand --password est déjà utilisé, car ils sont mutuellement exclusifs.
Demander un utilisateur et un mot de passe en utilisant la commande indiquée. Si aucune commande n'est indiquée, alors la commande dans la variable d'environnement WGET_ASKPASS est utilisée. Si WGET_ASKPASS n'est pas définie, alors la commande dans la variable d'environnement SSH_ASKPASS est utilisée.

Vous pouvez définir la commande par défaut pour use-askpass dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande.

Désactiver la prise en charge des URI internationalisés (IRI). Utiliser --iri pour l'activer. La prise en charge des IRI est activée par défaut.

Vous pouvez définir l'état par défaut de la prise en charge des IRI en utilisant la commande "iri" dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande.

Forcer wget à utiliser encodage comme système d'encodage par défaut. Cela influe sur la manière dont wget convertit les URL indiqués comme arguments de paramètres régionnaux vers UTF-8 pour la prise en charge d'IRI.

wget utilise la fonction "nl_langinfo()" et donc la variable d'environnement "CHARSET" pour obtenir les paramètres régionaux. Si cela échoue, ASCII sera utilisé.

Vous pouvez définir l'encodage local par défaut en utilisant la commande "local_encoding" dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande.

Forcer wget à utiliser l'encodage comme encodage par défaut du serveur distant. Cela affecte la façon dont wget convertit les URI trouvés dans les fichiers de l'encodage distant en UTF-8 lors d'une récupération récursive. Cette option n'est utile que pour la prise en charge d'IRI, pour interpréter les caractères qui ne sont pas ASCII.

Pour HTTP, l'encodage distant peut être trouvé dans l'en tête HTTP "Content-Type" et dans les méta-étiquettes HTML "Content-Type http-equiv".

Vous pouvez définir l'encodage par défaut avec la commande "remoteencoding" dans .wgetrc. Ce réglage peut être écrasé en ligne de commande.

Forcer wget à délier le fichier au lieu d'écraser le fichier existant. Cette option est utile pour le téléchargement dans le répertoire avec des liens en dur (« hardlinks »).

Ne pas créer de hiérarchie de répertoires lors d'une récupération récursive. Avec cette option activée, tous les fichiers sont sauvegardés dans le répertoire actuel, sans écrasement (si un nom apparait plus d'une fois, les noms de fichiers auront l'extension .n).
L'opposé de -nd : créer une hiérarchie de répertoires, même si une n'aurait pas été créée autrement. Par exemple, wget -x http://fly.srk.fer.hr/robots.txt sauvegardera les fichiers téléchargés dans fly.srk.fer.hr/robots.txt.
Désactiver la génération de répertoires préfixés par le nom d'hôte. Par défaut, l'invocation de wget avec -r http://fly.srk.fer.hr/ créera une structure de répertoires commençant par fly.srk.fer.hr/. Cette option désactive un tel comportement.
Utiliser le nom de protocole comme composant du répertoire des noms de fichiers locaux. Par exemple, avec cette option, wget -r http://hôte sera sauvegardé en http/hôte/... plutôt que seulement en hôte/....
Ignorer un certain nombre de composants du répertoire. Cela est utile pour obtenir un contrôle fin sur le répertoire où la récupération récursive sera enregistrée.

Prenons comme exemple le répertoire à l'adresse ftp://ftp.xemacs.org/pub/xemacs/. Si vous le récupérez avec -r, il sera sauvegardé localement sous ftp.xemacs.org/pub/xemacs/. Bien que l'option -nH peut supprimer la partie ftp.xemacs.org/, vous êtes encore coincé avec pub/xemacs. C'est là où --cut-dirs est vraiment pratique : il permet à wget de ne pas « voir » le nombre de composants de répertoire distant. Voici quelques exemples de la manière dont l'option --cut-dirs fonctionne.

 Pas d'options -> ftp.xemacs.org/pub/xemacs/  -nH ->
pub/xemacs/  -nH --cut-dirs=1 -> xemacs/  -nH --cut-dirs=2 >
.   --cut-dirs=1 -> ftp.xemacs.org/xemacs/  ...

Si vous voulez simplement vous débarrasser de la structure du répertoire, cette option est similaire à une combinaison de -nd et -P. Par contre, contrairement à -nd, --cut-dirs ne se perd pas avec des sous-répertoires (par exemple, avec -nH --cut-dirs=1, un sous-répertoire beta/ sera placé sur xemacs/beta, comme on pourrait l'espérer.

Désigner le préfixe de répertoire à préfixe. Le préfixe de répertoire est le répertoire où tous les autres fichiers et sous-répertoires vont être sauvegardés, c'est-à-dire le haut de l'arbre de récupération. C'est . (le répertoire actuel) par défaut.

Utiliser nom comme nom de fichier par défaut quand il n'est pas connu (c'est-à-dire pour les URL finissants avec une barre oblique), au lieu de index.html.
Si un fichier de type application/xhtml+xml ou text/html est téléchargé et que l'URL ne finit pas par l'expression rationnelle \.[Hh][Tt][Mm][Ll]?, cette option provoquera le rajout du suffixe .html au nom de fichier local. C'est utile, par exemple, lorsque vous mettez en miroir un site distant qui utilise des pages .asp, mais que vous voulez que les pages mises en miroir puissent être visualisées sur votre serveur Apache standard. Un autre usage appréciable pour cela est quand vous téléchargez du matériel généré par CGI. Une URL telle que http://site.com/article.cgi?25 sera sauvegardée comme article.cgi?25.html.

Notez que les noms de fichiers modifiés ainsi seront téléchargés à nouveau chaque fois que vous remettrez en miroir un site, car wget ne peut pas dire que le fichier local X.html correspond à l'URL X distante (étant donné qu'il ne sait pas encore que l'URL produit une sortie sous forme text/html ou application/xhtml+xml.

Avec la version 1.12 wget s'assure aussi que tous les fichiers téléchargés de forme text/css se terminent par le suffixe .css, et l'option a été renommée de --html-extension, pour mieux refléter son nouveau comportement. L'ancien nom de l'option est encore acceptable, mais devrait être considéré comme obsolète.

Depuis la version 1.19.2, wget s'assure aussi que tout fichier téléchargé avec un "Content-Encoding" de type br, compress, deflate ou gzip finisse avec le suffixe .br, .Z, .zlib et .gz respectivement.

À l'avenir, cette option devrait être assez étendue pour englober les suffixes d'autres types de contenus, incluant ceux qui ne sont pas analysés par wget.

Indiquer le nom d'utilisateur utilisateur et le mot de passe mot_de_passe sur un serveur HTTP. Selon le type d'authentification par question-réponse, wget encodera en utilisant à la fois le schéma d'authentification "basic" (non-sécurisé), "digest" ou "NTLM" de Windows.

Une autre manière d'indiquer le nom d'utilisateur et le mot de passe est de les spécifier dans l'URL. Les deux méthodes révèlent votre mot de passe à quiconque se donne la peine d'exécuter "ps"). Pour empêcher que les mots de passe ne soient vus, utilisez --use-askpass ou stockez les dans .wgetrc ou .netrc, et assurez vous de protéger ces fichiers des autres utilisateurs avec "chmod". Si les mots de passe sont très importants, ne les laissez pas traîner dans ces fichiers non plus (éditez les fichiers et effacez-les après que wget a commencé le téléchargement).

Désactiver la fonction « keep-alive » pour les téléchargements HTTP. Normalement, wget demande au serveur de laisser la connexion ouverte pour que, lorsque vous téléchargez plus d'un document sur le même serveur, ils soient transférés sur la même connexion TCP. Cela économise du temps et aussi réduit la charge sur le serveur.

Cette option a son utilité quand, pour une raison quelconque, les connexions persistantes (keep-alive) ne fonctionnent pas pour vous, dû par exemple à un bogue du serveur ou en raison de l'incapacité des scripts côté serveur à gérer les connexions.

Désactiver le cache coté serveur. Dans ce cas, wget enverra les directives appropriées (Cache-Control: no-cache et Pragma: no-cache) au serveur distant pour recevoir les fichier du service distant, au lieu de renvoyer la version mise en cache. Cela est surtout utile pour retrouver et vider les documents obsolètes sur des serveurs mandataires.

La mise en cache est autorisée par défaut.

Désactiver l'utilisation des cookies. Les cookies sont un mécanisme permettant de conserver l'état du serveur. Le serveur envoie au client un cookie utilisant l'en-tête "Set-Cookie" et le client répond avec le même cookie lors de requêtes supplémentaires. Comme les cookies autorisent les propriétaires du serveur à garder une trace des visiteurs et pour les sites de s'échanger ces informations, certains considèrent cela comme une atteinte à la vie privée. Par défaut, les cookies sont utilisés ; cependant, il n'y a pas de stockage de cookies par défaut.
Charger les cookies d'un fichier avant la première récupération HTTP. fichier est un fichier texte dans le format utilisé à l'origine par les fichiers cookies.txt de Netscape.

Vous utiliserez généralement cette option pour la mise en place d'un miroir de sites qui exigent que vous soyez connecté pour accéder à tout ou partie de leur contenu. Le processus de connexion fonctionne généralement de la manière suivante : le serveur Web émet un cookie HTTP après avoir reçu et vérifié vos identifiants. Le cookie est alors renvoyé par le navigateur pour accéder à cette partie du site, et prouve ainsi de votre identité.

La mise en miroir d'un tel site nécessite que wget renvoie les même cookies que ceux envoyés par le navigateur lors de la communication avec le site. Cela est fait par --load-cookies ; il suffit d'indiquer à wget l'emplacement du fichier cookies.txt et il enverra les mêmes cookies que votre navigateur enverrait dans la même situation. Les différents navigateurs conservent les fichiers cookies textuels à des endroits différents :

"Netscape 4.x."
Les cookies sont dans ~/.netscape/cookies.txt.
"Mozilla and Netscape 6.x."
Le fichier de cookies de Mozilla se nomme aussi cookies.txt et se trouve quelque part sous ~/.mozilla, dans le répertoire de votre profil. Le nom de chemin se termine généralement en quelque chose comme ~/.mozilla/default/chaîne_bizarre/cookies.txt.
"Internet Explorer."
Vous pouvez produire un fichier cookie que wget peut utiliser en utilisant le menu Fichier, Import et Export, Export de cookies. Cela a été testé avec Internet Explorer 5 ; il n'est pas garanti que cela fonctionne avec des versions plus récentes.
"Other browsers."
Si vous utilisez un autre navigateur pour créer vos cookies, --load-cookies ne pourra fonctionner que si vous pouvez situer ou créer un fichier cookie dans le format Netscape comme attendu par wget.

Si vous ne pouvez pas utiliser --load-cookies, il devrait exister une alternative. Si votre navigateur prend en charge un "gestionnaire de cookie", vous pouvez l'utiliser pour visualiser les cookies utilisés pour accéder au site que vous mettez en miroir. Écrire le nom et la valeur du cookie, et donner des instructions manuellement à wget pour qu'il envoie ces cookies, en contournant le gestionnaire de cookie « officiel » :

 wget --no-cookies --header "Cookie: <nom>=<valeur>"
Sauvegarder les cookies dans fichier avant de quitter. Cela ne sauvegardera pas les cookies qui ont expirés ou qui n'ont pas de délai d'expiration (nommés les « cookies de session »), mais voir aussi --keep-session-cookies.
Lorsque indiqué, fait que --save-cookies sauvegarde aussi les cookies de session. Les cookies de session ne sont normalement pas sauvegardés, car ils sont sensés être gardés en mémoire et oubliés lorsque vous quittez le navigateur. Les sauvegarder est utile sur les sites qui nécessitent une identification ou une visite de la page d'accueil avant que vous puissiez accéder à certaines pages. Avec cette option, de multiples exécutions de wget sont considérées comme une seule session de navigateur tant que le site est concerné.

Comme le format de fichier de cookie ne contient généralement pas les cookies de session, wget les marque avec un délai d'expiration de 0. --load-cookies de wget les reconnaît comme cookies de session, mais cela pourrait être confus pour d'autres navigateurs. Prenez en compte aussi que les cookies chargés ainsi seront traités comme d'autres cookies de session, donc si vous voulez que --save-cookies les conserve à nouveau, vous devez utiliser --keep-session-cookies à nouveau.

Hélas, quelques serveurs HTTP (les programmes CGI, pour être précis) envoient de faux en-têtes "Content-Length", ce qui rend wget fou, car il pense que tout le document n'a pas été récupéré. Vous pouvez repérer ce syndrome si wget tente à plusieurs reprises de récupérer le même document, en affirmant à chaque fois que la connexion (par ailleurs normale) a été fermée au même instant précis.

Avec cette option, wget ignorera l'en-tête "Content-Length", comme s'il n'avait jamais existé.

Envoyer header-line avec le reste des en-têtes dans chaque requête HTTP. L'en-tête fourni est envoyé tel quel, ce qui signifie qu'il doit contenir le nom et la valeur séparés par un deux-points, et ne doit pas contenir de passage à la ligne.

Vous pouvez définir plus d'un en-tête additionnel en indiquant --header plus d'une fois.

 wget --header='Accept-Charset: iso-8859-2' \ 
--header='Accept-Language: hr' \  http://fly.srk.fer.hr/

L'indication d'une chaîne vide comme valeur d'en-tête effacera tous les en-têtes précédemment définis par l'utilisateur.

Avec wget 1.10, cette option peut être utilisée pour écraser les en-têtes qui autrement auraient été générés automatiquement. Cet exemple donne l'instruction à wget de se connecter à l'hôte local, mais en indiquant truc.machin dans l'en-tête "Host" :

 wget --header="Host: truc.machin" http://localhost/

Dans les versions de wget antérieures à 1.10, une telle utilisation de --header provoquait l'envoi d'en-têtes en double.

Choisir le type de compression à utiliser. Les valeurs permises sont auto, gzip et none.

Si auto ou gzip sont indiqués, wget demande au serveur de compresser le fichier en utilisant le format gzip de compression. Si le serveur compresse le fichier et répond avec le champ d'en-tête "Content-Encoding" configuré de manière adéquate, le fichier sera décompressé automatiquement.

Si none est indiqué, wget ne demandera pas au serveur de compresser le fichier et ne décompressera aucune réponse du serveur. C'est le comportement par défaut.

La prise en charge de la compression est actuellement expérimentale. Au cas où la compression est activée, merci de rapporter tout bogue à "bug-wget@gnu.org".

Indique le nombre maximal de redirections à suivre pour une ressource. Par défaut, c'est 20, ce qui est généralement largement plus que suffisant. Cependant, en certaines occasions où vous voulez en autoriser plus (ou moins), c'est l'option à utiliser.
Indiquer le nom d'utilisateur utilisateur et le mot de passe mot_de_passe pour l'authentification sur un serveur mandataire. wget les encodera en utilisant le schéma d'authentification "basic".

Des considérations de sécurité similaires à celles avec --http-password sont pertinentes ici aussi.

Inclure l'en-tête « Referer: url » dans la requête HTTP. Cela est utile pour récupérer des documents avec un traitement de serveur qui suppose qu'ils sont toujours récupérés par des navigateurs web interactifs et ne s'en sortent correctement que lorsque le Referer est réglé sur l'une des pages qui pointent vers eux.
Sauvegarder les en-têtes envoyés par le serveur HTTP dans le fichier, précédant le contenu actuel, avec une ligne vide comme séparateur.
S'identifier comme agent-string pour le serveur HTTP.

Le protocole HTTP autorise les clients à s'identifier eux-mêmes en utilisant un champ d'en-tête "User-Agent". Cela permet de différencier les logiciels WWW, généralement dans des buts de statistiques ou pour retracer les violations de protocole. Normalement, wget s'identifie comme Wget/version, où version est le numéro de la version actuelle de wget.

Cependant, certains sites sont connus pour imposer la politique d'adaptation de la sortie en fonction des informations fournies par le "User-Agent". Bien que ce ne soit pas une si mauvaise idée en théorie, il y a eu des abus par des serveurs refusant l'information à des clients autres que Netscape (historiquement), ou plus fréquemment, Microsoft Internet Explorer. Cette option vous permet de changer la ligne "User-Agent" fournie par wget. Utiliser cette option est déconseillé, à moins de savoir réellement ce que vous faites.

Indiquer un user agent vide avec --user-agent="" demandera à wget de ne pas envoyer d'en-tête "User-Agent" dans les requêtes HTTP.

Utiliser POST comme méthode pour toutes les requêtes HTTP et les envoyer dans les corps de requête. --post-data envoie chaîne comme données, alors que --post-file envoie le contenu de fichier. À part cela, ces options fonctionnent exactement de la même manière. En particulier, les deux s'attendent à du contenu sous la forme "clé1=valeur1&clé2=valeur2", avec un encodage-pourcent (percent encoding) des caractères spéciaux ; la seule différence est que l'une attend son contenu comme paramètre de ligne de commande et l'autre accepte son contenu d'un fichier. En particulier --post-file n'est pas fait pour transmettre des fichiers sous forme de pièces jointes : ceux-là doivent apparaitre comme des données "clé=valeur" (avec l'encodage-pourcent adéquat) juste comme tout le reste. wget ne prend pas actuellement en charge "multipart/form-data" pour transmettre des données POST, mais seulement "application/x-www-form-urlencoded". Seule'une des options --post-data ou --post-file doit être spécifiée.

Veuillez noter que wget n'exige pas que le contenu soit de la forme "clé1=valeur1&clé2=valeur2", et ne le teste pas non plus. wget transmettra simplement toutes les données qui lui sont fournies. La plupart des serveurs s'attendent toutefois à ce que les données POST soient dans le format ci-dessus lors du traitement des formulaires HTML.

Lors de l'envoi d'une requête POST à l'aide de l'option --post-file, wget traite le fichier comme un fichier binaire et envoie chaque caractère de la requête POST sans supprimer les caractères de fin de ligne ou de saut de page. Tout autre caractère de contrôle dans le texte sera aussi envoyé tel quel dans la requête POST.

Merci de prendre en compte que wget doit connaître la taille des données POST à l'avance. C'est pourquoi l'argument à "--post-file" doit être un fichier normal ; spécifier une FIFO ou quelque chose comme /dev/stdin ne fonctionnera pas. La façon de contourner cette limite inhérente à HTTP/1.0. n'est pas très claire. Bien que HTTP/1.0. introduise le transfert morcelé qui ne nécessite pas de connaître la longueur à l'avance, un client ne peut pas utiliser le tronçonnage avant de savoir qu'il parle à un serveur HTTP/1.1. Et il ne peut pas le savoir avant d'avoir reçu une réponse, qui a son tour nécessite qu'une requête ait abouti - le problème de l'œuf et de la poule).

Note : Depuis la version 1.15 si wget est redirigé après que la requête POST a terminé, son comportement dépendra du code de la réponse renvoyé par le serveur. Dans le cas d'un 301 Moved Permanently, 302 Moved Temporarily ou 307 Temporary Redirect, wget en accord avec la RFC2616, continuera à envoyer une requête POST. Dans le cas où un serveur veut que le client change la méthode de requête lors de la redirection, il devrait envoyer un code de réponse 303 See Other .

Cet exemple montre comment se connecter à un serveur en utilisant POST et ensuite procéder au téléchargement des pages souhaitées, vraisemblablement accessibles uniquement aux utilisateurs autorisés :

 # Se connecter au serveur. Cela ne peut être fait qu'une fois.  wget
--save-cookies cookies.txt \  --post-data
'user=truc&password=machin' \  http://example.com/auth.php  
# Maintenant prendre la ou les pages qui nous intéressent .   wget
--load-cookies cookies.txt \  -p
http://example.com/interesting/article.php

Si le serveur utilise des cookies de session pour tracer l'authentification de l'utilisateur, l'exemple ci-dessus ne fonctionnera pas car --save-cookies ne les sauvegardera pas (comme aucun navigateur) et le fichier cookies.txt sera vide. Dans ce cas, utiliser --keep-session-cookies avec --save-cookies pour forcer la sauvegarde des cookies de session.

Pour les besoins des scripts RESTful, wget permet l'envoi d'autres méthodes HTTP sans avoir besoin de les définir explicitement en utilisant --header=Header-Line. wget utilisera n'importe quelle chaîne qui lui sera passée après --method comme méthode HTTP pour le serveur.
Doit être positionné lorsque des données additionnelles nécessitent d'être envoyées au serveur avec la méthode préconisée par l'utilisation de --method. --body-data envoie une chaîne comme données, alors que --body-file envoie le contenu de fichier. Autrement, ils fonctionnent exactement pareil.

Actuellement, --body-file ne transmet pas les fichiers comme un tout. wget ne prend actuellement pas en charge "multipart/form-data" pour la transmission de données, mais seulement "application/x-www-form-urlencoded". Dans le futur, cela devrait changer pour que wget puisse envoyer le fichier --body-file comme un fichier complet, au lieu d'envoyer son contenu au serveur. Veuillez prendre en compte que wget nécessite de connaître le contenu des données BODY à l'avance et donc l'argument de --body-file devrait être un fichier ordinaire. Voir --post-file pour des explications plus détaillées. Une seule des options --body-data et --body-file devrait être spécifiée.

Si wget est redirigé après la fin de la requête, wget suspend la méthode en cours et envoie une requête GET jusqu'à ce que la redirection soit terminée. Cela est vrai pour tous les codes de redirection de réponse à l’exception de 307 Temporary Redirect qui est utilisé pour indiquer explicitement que la méthode de requête ne devrait pas changer. Une autre exception est quand la méthode est positionnée à "POST", auquel cas les règles de redirection indiquées avec --post-data sont suivies.

Si l'option est positionnée, la prise en charge expérimentale (pas complètement fonctionnelle) des en-têtes "Content-Disposition" est activée. Cela peut actuellement entraîner des allers-retours supplémentaires vers le serveur pour une requête "HEAD", et souffre de quelques bogues connus, c'est pourquoi ce n'est pas actuellement activé par défaut.

Cette option est utile pour quelques programmes de téléchargement CGI qui utilisent des en-têtes "Content-Disposition" pour décrire à quoi devrait ressembler le nom d'un fichier téléchargé.

Quand il est combiné avec --metalink-over-http et --trust-server-names, un fichier Content-Type: application/metalink4+xml est nommé en utilisant le champ de nom de fichier de "Content-Disposition", s'il est disponible.

Si cela est activé, wget ne sautera pas le contenu lorsque le serveur répond avec un code d'état http qui indique une erreur.
Si cela est activé, lors d'une redirection, le nom du fichier local sera basé sur l'URL de redirection. Par défaut le nom du fichier local est basé sur l'URL d'origine. Lors d'une recherche récursive, cela peut être utile car dans de nombreux sites web, les URL redirigées correspondent à une structure de fichiers sous-jacente, alors que les URL de liens ne le font pas.
Si cette option est passée, wget enverra une information d'authentification HTTP Basic (nom d'utilisateur et mot de passe en texte clair) pour toutes les requêtes, comme le fait par défaut wget 1.10.2 et antérieurs.

L'utilisation de cette option est déconseillée, et est destinée uniquement à la prise en charge de quelques serveurs obscurs qui n'envoient jamais d'authentification par question-réponse HTTP, mais acceptent les informations d'authentification non sollicitées, disons, en plus de l'authentification par formulaire.

Considérer les erreurs de l'hôte, telles que "Échec temporaire dans la résolution du nom", comme des erreurs non fatales et transitoires.
Considérer les codes de réponse HTTP donnés comme des erreurs non-fatales et transitoires. Fournir une liste de codes de réponse HTTP à trois chiffres séparés par des virgules comme argument. Utile pour travailler dans certaines circonstances où les réessais sont nécessaires, mais où le serveur répond avec un code d'erreur que wget ne réessaye pas normalement. Ces erreurs devraient être 503 (Service non disponible) et 429 (Trop de requêtes). Les tentatives activées par cette option sont effectuées sous réserve des limitations normales de wget en matière de délais et de nombre de tentatives.

L'utilisation de cette option n'est prévue que pour des cas d'utilisation particuliers et n'est généralement pas recommandée, car elle peut forcer des tentatives même dans les cas où le serveur essaie réellement de réduire sa charge. Veuillez l'utiliser à bon escient et seulement si vous savez ce que vous faites.

Pour la prise en charge des téléchargements HTTP (HTTPS) chiffrés, wget doit être compilé avec une bibliothèque SSL externe. Habituellement par défaut c'est GnuTLS. En plus, wget prend aussi en charge HSTS (HTTP Strict Transport Security). Si wget est compilé sans la prise en charge de SSL, aucune de ces options n'est disponible.

Choisir le protocole de sécurité à utiliser. Les valeurs autorisées sont auto, SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2, TLSv1_3 et PFS. Si auto est utilisé, le choix est donné à la bibliothèque SSL de choisir le protocole approprié automatiquement, qui s'achève par l'envoi d'un salut TLSv1. C'est le comportement par défaut.

Indiquer SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2 ou TLSv1_3 force l'utilisation du protocole correspondant. Cette fonction est utile lorsque l'on s'adresse à des implémentations de serveur SSL anciennes et boguées qui rendent le choix de la version correcte du protocole difficile pour la bibliothèque SSL sous-jacente. Heureusement, de tels serveurs sont assez rares.

La spécification de PFS impose l'utilisation des suites de chiffrement dites « Perfect Forward Security ». Pour faire court, PFS ajoute une sécurité en créant une clé à usage unique pour chaque connexion SSL. Cela a un impact un peu plus important sur le CPU du client et du serveur. Nous utilisons des chiffrements connus pour être sûrs (par exemple, pas de MD4) et le protocole TLS. Ce mode exclut également de manière explicite les méthodes d'échange de clés non PFS, telles que RSA.

En mode récursif, seuls les liens HTTPS sont suivis.
Définir la chaîne de liste de chiffrement. Normalement cette chaîne définit les suites de chiffrement et autres options SSL/TLS que l'utilisateur voudrait utiliser, avec un ordre de préférence (GnuTLS l'appelle « chaîne prioritaire »). Cette chaîne sera envoyée littéralement au moteur SSL/TLS (OpenSSL ou GnuTLS) et donc son format et sa syntaxe en dépendront. wget ne la traitera ni ne la manipulera en aucune façon. Se référer à la documentation d'OpenSSL ou de GnuTLS pour de plus amples informations.
Ne pas vérifier le certificat du serveur auprès des autorités de certification disponibles. Ne pas requérir non plus que le nom d'hôte de l'URL corresponde au nom commun présenté par le certificat.

Depuis wget 1.10, le comportement par défaut est de vérifier le certificat du serveur auprès des autorités de certification reconnues, cassant l'établissement de la liaison SSL et stoppant le téléchargement si la vérification échoue. Aussi, même si cela procure des téléchargements plus sûrs, cela casse l'interopérabilité avec certains sites qui fonctionnent avec des versions précédentes de wget, en particulier ceux qui utilisent des certificats auto-signés, expirés ou non valables. Cette option force le mode "insecure" qui transforme les erreurs de vérification de certificats en avertissements, permettant ainsi de poursuivre.

Si vous rencontrez des erreurs "certificate verification" ou qui indiquent "le nom courant ne correspond pas au nom d'hôte demandé", vous pouvez utiliser cette option pour outrepasser la vérification. N'utilisez cette option que si vous êtes convaincu par un autre moyen de l'authenticité du site, ou si vraiment peu vous importe la validité de son certificat. C'est presque toujours une mauvaise idée de ne pas vérifier les certificats lors de la transmission de données confidentielles ou importantes. Pour les certificats auto-signés, vous devriez télécharger le certificat pour le vérifier au lieu de forcer en mode non sécurisé. Si vous êtes vraiment sûr de ne vouloir aucune vérification de certificat, vous pouvez indiquer --check-certificate=quiet pour dire à wget de ne pas afficher d'avertissements au sujet des certificats non valables, bien que dans la plupart des cas ce soit la mauvaise chose à faire.

Utiliser le certificat du client stocké dans fichier. Cela est nécessaire pour les serveurs qui sont configurés pour demander les certificats des clients qui s'y connectent. Normalement, un certificat n'est pas demandé et cette option est optionnelle.
Indiquer le type de certificat du client. Les valeurs autorisées sont PEM (par défaut) et DER, aussi connu comme ASN1.
Lire la clé privée dans fichier. Cela vous permet de fournir la clé privée dans un fichier séparé du certificat.
Indiquer le type de la clé privée. Les valeurs acceptées sont PEM (par défaut) et DER.
Utiliser fichier comme fichier contenant le paquet d'autorités de certification ("CA") pour vérifier les pairs. Les certificats doivent être au format PEM.

Sans cette option wget cherche les certificats CA aux endroits spécifiés par le système, choisis par OpenSSL lors de son installation.

Indiquer le répertoire contenant les certificats CA au format PEM. Chaque fichier contient un certificat CA, et le nom du fichier est basé sur une valeur de hachage dérivée du certificat. Cela est réalisé en traitant un répertoire de certificats avec l'utilitaire "c_rehash" fourni avec OpenSSL. L'utilisation de --ca-directory est plus efficace que --ca-certificate lorsque plusieurs certificats sont installés car cela permet à wget de récupérer les certificats sur demande.

Sans cette option wget cherche les certificats CA aux endroits spécifiés par le système, choisis par OpenSSL lors de son installation.

Indiquer un fichier CRL dans fichier. Cela est nécessaire pour les certificats révoqués par les Autorités de Certifications.
Dire à wget d'utiliser la clé publique indiquée (ou les hachages) pour vérifier le pair. Cela peut être un chemin qui contient une seule clé publique au format PEM ou DER, ou tout nombre de hachages sha256 encodés en base64 précédés de "sha256//" et séparés par ";"

Lors de la négociation d'une connexion TLS ou SSL, le serveur envoie un certificat prouvant son identité. Une clé publique est extraite de ce certificat et si cela ne correspond pas exactement à une des clés publique fournies à cette option, wget annulera la connexion avant l'envoi ou la réception de données.

[OpenSSL et LibreSSL seulement] Utiliser fichier comme source de données aléatoires pour ensemencer le générateur de nombres pseudo-aléatoires sur les systèmes sans /dev/urandom.

Sur de tels systèmes, la bibliothèque -SSL a besoin d'une source extérieure de données aléatoires pour s'initialiser. Les données aléatoires peuvent être fournies par EGD (voir --egd-file ci dessous) ou lues sur une source extérieure spécifiée par l'utilisateur. Si cette option n'est pas indiquée, wget cherchera les données aléatoires dans $RANDFILE ou, s'il n'est pas défini, dans HOME/.rnd.

Si vous obtenez l'erreur "Could not seed OpenSSL PRNG; disabling SSL.", vous devriez fournir des données aléatoires en utilisant l'une des méthodes décrites ci-dessus.

[seulement pour OpenSSL] Utiliser fichier comme socket EGD. EGD signifie Entropy Gathering Daemon, un programme de l'espace utilisateur qui collecte des données à partir de diverses sources système imprévisibles et les met à la disposition d'autres programmes qui pourraient en avoir besoin. Les logiciels de chiffrement, tels que la bibliothèque SSL, ont besoin de sources d'aléas non répétitifs pour ensemencer le générateur de nombres aléatoires utilisé pour produire des clés cryptographiques solides.

OpenSSL autorise l'utilisateur à indiquer sa propre source d'entropie en utilisant la variable d'environnement "RAND_FILE". Si cette variable n'est pas définie, ou si le fichier indiqué ne produit pas assez de caractères aléatoires, OpenSSL lira les données aléatoires du socket EGD indiqué en utilisant cette option.

Si cette option n'est pas indiquée (et que la commande équivalente de démarrage n'est pas utilisée), EGD n'est jamais contacté. EGD n'est pas nécessaire sur les systèmes Unix modernes qui prennent en charge /dev/urandom.

wget prend en charge HSTS (HTTP Strict Transport Security, RFC 6797) par défaut. Utiliser --no-hsts pour faire que wget se comporte comme un UA non compatible avec HSTS. Comme conséquence wget ignorera tous les en-têtes "Strict-Transport-Security", et ne voudra appliquer aucune politique HSTS existante.
Par défaut, wget stocke sa base de données HSTS dans ~/.wget-hsts. Vous pouvez utiliser --hsts-file pour écraser cela. wget utilisera le fichier fourni comme base de données HSTS. Un tel fichier doit être conforme au format de base de données HSTS utilisé par wget. Si wget ne peut pas analyser le fichier fourni, le comportement est indéterminé.

La base de données HSTS de wget est un fichier en texte brut. Chaque ligne contient une entrée HSTS (c'est-à-dire, un site qui a fourni un en-tête "Strict-Transport-Security" et a néanmoins indiqué une politique concrète HSTS à appliquer). Les lignes commençant par un croisillon ("#") sont ignorées par wget. Veuillez noter qu'en dépit de cette facilité de lecture, la création manuelle de la base de données HSTS n'est généralement pas une bonne idée.

Une entrée de ligneHSTS consiste en plusieurs champs séparés par un ou plusieurs espaces blancs :

"<hostname> SP [<port>] SP <include subdomains> SP <created> SP <max-age>"

Les champs hostname et port indiquent le nom de l'hôte et le port sur lequel est appliquée la politique HSTS indiquée. Le champ port peut être zero, et le sera, dans la majorité des cas. Cela signifie que le numéro de port ne sera pas pris en compte lors de la décision d'appliquer telle ou telle politique HSTS pour une requête donnée (seul le nom d'hôte sera évalué). Lorsque port est différent de zéro, à la fois le nom d'hôte et le port seront évalués et la politique HSTS sera appliquée si les deux correspondent. Cette option a été incluse à des fins de test et de développement surtout. La suite de tests de wget (dans testenv/) crée des bases de données HSTS avec des ports explicites dans le but d'assurer un comportement correct à wget. L'utilisation de politiques HSTS sur des ports autres que ceux par défaut est déconseillée par la RFC 6797 (voir l'appendice B "Differences between HSTS Policy and Same-Origin Policy"). Ainsi, cette option ne devrait pas être utilisée dans des environnements en production et le port sera typiquement zéro. Les trois derniers champs font ce qu'on attend d'eux. Le champ include_subdomains peut être 1 ou 0 et indique si les sous-domaines du domaine cible devraient aussi faire partie de la politique HSTS donnée. Les champs create et max-age portent l'horodatage de la création de l'entrée (comme vu la première fois par wget) et la valeur définie par HSTS "max-age", qui définit combien de temps la politique HSTS devrait rester activée, mesuré en secondes écoulées depuis le délai stocké dans created. Une fois ce temps écoulé, la politique HSTS ne sera plus valable et sera finalement enlevée de la base de données.

Si vous fournissez votre propre base de données HSTS à l'aide de --hsts-file, sachez que wget peut modifier le fichier fourni si un changement se produit entre les politiques HSTS demandées par les serveurs distants et celles du fichier. Quand wget se termine, il met effectivement à jour la base de données HSTS en réécrivant le fichier de base de données avec les nouvelles entrées.

Si le fichier fourni n'existe pas, wget en créera un. Ce fichier contiendra les nouvelles entrées HSTS. Si aucune entrée HSTS n'a été crée (aucun en-tête "Strict-Transport-Security" n'a été envoyé par aucun des serveurs) alors aucun fichier n'est créé, même pas un vide. Ce comportement s'applique aussi au fichier de base de données par défaut (~/.wget-hsts) : il ne sera pas créé, sauf par un serveur qui force la politique HSTS.

L'attention est mise sur le fait de ne pas écraser de possibles changements faits par d'autres wget au même moment sur la base de données HSTS. Avant de déposer les entrées HSTS mises à jour dans le fichier, wget le relit et fusionne les modifications.

Il est déconseillé d'utiliser une base de données HSTS personnalisée ou de modifier une base existante. Pour plus d'informations sur les menaces de sécurité potentielles découlant d'une telle pratique, consultez la section 14 "Considérations de sécurité" de la RFC 6797, en particulier la section 14.9 "Manipulation créative du stockage de politiques HSTS".

Utiliser fichier comme fichier WARC de destination.
Utiliser chaîne dans l'enregistrement warcinfo.
Définir la taille maximale des fichiers WARC à taille.
Écrire les fichiers index CDX.
Ne pas conserver les documents répertoriés dans ce fichier CDX.
Ne pas compresser les fichiers WARC avec GZIP.
Ne pas calculer les sommes de contrôle SHA1.
Ne pas stocker le fichier journal dans un enregistrement WARC.
Indiquer l'emplacement des fichiers temporaires créés par le rédacteur WARC.

Indiquer le nom de l'utilisateur utilisateur et le mot de passe mot_de_passe sur un serveur FTP. Sans cela ou l'option de démarrage adéquate, le mot de passe par défaut est -wget@, normalement utilisé pour un FTP anonyme

Le nom d'utilisateur et le mot de passe peuvent être indiqués dans l'URL. Les deux méthodes révèlent votre mot de passe à quiconque se donne la peine d'exécuter "ps". Pour empêcher que vos mots de passe soient vus, stockez les dans .wgetrc ou .netrc, et assurez-vous de protéger ces fichiers des autres utilisateurs avec "chmod". Si les mots de passe sont très importants, vous ne devriez pas les laisser traîner dans ces fichiers non plus (éditez les fichiers et effacez-les après que wget a commencé le téléchargement).

Ne pas supprimer les fichiers temporaires .listing générés par les récupérations FTP. Normalement, ces fichiers contiennent les listings bruts de répertoires reçus des serveurs FTP. Ne pas les supprimer peut être utile pour des objectifs de débogage, ou quand vous voulez être facilement capable de vérifier le contenu des répertoires du serveur distant (par exemple, pour vérifier que le miroir que vous lancez est complet).

Remarquez que même si wget écrit dans un nom de fichier connu pour ce fichier, ce n'est pas une faille de sécurité dans le scénario d'un utilisateur faisant de .listing un lien symbolique vers /etc/passwd ou autre et demandant à "root" d'exécuter wget dans son répertoire. Selon les options utilisées, soit wget refusera d'écrire dans .listing, faisant échouer l'opération de globbing/récursion/horodatage, soit le lien symbolique sera supprimé et remplacé par le fichier .listing réel, soit le listing sera écrit dans un fichier .listing.numéro.

Même dans cette situation, cela n'est pas un problème, bien que, "root" ne devrait jamais lancer wget dans un répertoire utilisateur non sécurisé. Un utilisateur pourrait faire quelque chose d'aussi simple qu'un lien de index.html à /etc/passwd et demander à "root" de lancer wget avec -N ou -r et ainsi écraser le fichier.

Désactiver le globbing FTP. Globbing (englober) réfère à l'utilisation de caractères spéciaux (jokers) à la façon du shell, tels que *, ?, [ et ] pour retrouver plus d'un fichier dans le même répertoire en une fois, comme : 
 wget ftp://gnjilux.srk.fer.hr/*.msg

Par défaut, la fonction de globbing est activée si l'URL contient un caractère de globbing. Cette option peut être utilisée pour activer ou désactiver le globbing de manière permanente.

Vous devrez peut-être mettre entre guillemets l'URL pour le protéger de l'expansion par votre interpréteur de commandes. Le globbing fait que wget cherche une liste de répertoires, ce qui est spécifique au système. C'est pourquoi cela ne fonctionne actuellement qu'avec les serveurs FTP Unix (et ceux qui émulent la sortie "ls" d'Unix).

Désactiver l'utilisation du mode de transfert FTP passif. Le mode FTP passif implique que le client se connecte au serveur pour établir la connexion de données plutôt que l'inverse.

Si la machine est connectée directement à Internet, FTP actif et passif devraient fonctionner aussi bien l'un que l'autre. Derrière la plupart des configurations de pare-feu et de NAT, le FTP passif a plus de chance de fonctionner. Cependant, dans certaines configurations rares de pare-feu, le FTP actif fonctionne alors que le FTP passif ne fonctionne pas. Si vous pensez que c'est le cas, utilisez cette option, ou définissez "passive_ftp=off" dans votre fichier init.

Préserver les permissions de fichiers distants au lieu des permissions définies par umask.
Par défaut, lors de la récupération récursive des répertoires FTP et qu'un lien symbolique est rencontré, le lien symbolique est suivi et les fichiers pointés sont récupérés. Actuellement, wget ne suit pas les liens symboliques pour télécharger les répertoires récursivement, bien que cette option pourrait être ajoutée dans le futur.

Lorsque --retr-symlinks=no est indiqué, le fichier pointé n'est pas téléchargé. À la place, un lien symbolique correspondant est créé sur le système de fichiers local. Le fichier pointé ne sera pas récupéré sauf si la récupération récursive le rencontre autrement et le télécharge de toutes façons. Cette option pose un risque de sécurité où un serveur FTP malveillant pourrait amener wget à écrire dans des fichiers situés en dehors des répertoires prévus par le biais d'un fichier .LISTING spécialement contrefait.

Notez que cette option n'a aucun effet lors de la récupération d'un fichier (pas d'un répertoire) parce qu'il a été indiqué dans la ligne de commandes plutôt que trouvé par récursion. Les liens symboliques sont toujours suivis dans ce cas.

Cette option indique à wget d'utiliser FTPS implicitement. FTPS implicite consiste à initialiser SSL/TLS au tout début de la connexion de contrôle. Cette option n'envoie pas de commande "AUTH TLS" : elle présume que le serveur parle FTPS et démarre directement une connexion SSL/TLS. Si la tentative réussit, la session continue juste comme FTPS normal ("PBSZ" et "PROT" sont envoyés, etc). FTPS implicite n'est plus un prérequis pour les implémentations FTPS, donc beaucoup de serveurs ne le prennent pas en charge. Si --ftps-implicit est passé et qu'aucun numéro de port explicite n'est indiqué, le port par défaut pour le FTPS implicite, 990, sera utilisé, au lieu du port par défaut pour le FTPS « normal » (explicite), qui est le même que celui pour FTP, 21.
Ne pas reprendre la session SSL/TLS dans le canal de données. Lors du démarrage d'une connexion de données, wget essaiera de reprendre la session SSL/TLS précédemment démarrée dans la connexion de contrôle. La reprise de session SSL/TLS évite d'effectuer une poignée de main entièrement nouvelle en réutilisant les paramètres SSL/TLS d'une session précédente. Habituellement, les serveurs FTPS souhaitent cela, aussi wget le fait par défaut. Dans de rares circonstances néanmoins, il serait possible de souhaiter démarrer une session SSL/TLS entièrement nouvelle à chaque connexion de données. C'est à cela que --no-ftps-resume-ssl est destiné.
Toutes les connexions de données seront en texte brut. Seule la connexion de contrôle sera sous SSL/TLS. wget enverra une commande "PROT C" pour réaliser cela, ce qui doit être approuvé par le serveur.
Revenir à FTP si FTPS n'est pas pris en charge par le serveur cible. Pour des raisons de sécurité, cette option n'est pas déclarée par défaut. Le comportement par défaut est de quitter avec une erreur. Si un serveur ne répond pas avec succès à la commande initiale "AUTH TLS", ou dans le cas du FTPS, implicite si la tentative de connexion SSL/TLS initiale est rejetée, on considère ce serveur comme ne prenant pas en charge le FTPS.

Activer la récupération récursive. La profondeur maximale par défaut est 5.
Définir le nombre maximal de sous-répertoires dans lesquels wget fera une récursion à profondeur. Dans le but d'éviter de télécharger de très grands sites web lors de l'utilisation de la récursion, cela est limité à une profondeur de 5 par défaut, c'est à dire qu'il traversera au plus 5 répertoires en profondeur en commençant à l'URL fournie. Indiquer -l 0 ou -l inf pour une profondeur de récursion infinie. 
 wget -r -l 0 http://<site>/1.html

Idéalement, on pourrait s'attendre à ce que cela ne télécharge que 1.html, mais malheureusement ce n'est pas le cas, car -l 0 est équivalent à -l inf (ce qui est la récursion infinie). Pour télécharger une seule page HTML (ou quelques pages), indiquez les sur la ligne de commande et délaissez -r et -l. Pour télécharger les éléments essentiels à l'affichage d'une seule page HTML, voir page requisites.

Cette option indique à wget de supprimer chaque fichier qu'il télécharge, après l'avoir fait. Elle est utile pour précharger des pages populaires à travers un mandataire, par exemple : 
 wget -r -nd --delete-after http://toto.com/~page/populaire/

L'option -r est pour récupérer récursivement et -nd pour ne pas créer de répertoires.

Remarquez que --delete-after efface les fichiers sur la machine locale. Cela n'émet pas la commande DELE pour les sites FTP distants, par exemple. Notez aussi que lorsque --delete-after est indiqué, --convert-links est ignoré, ainsi les fichiers .orig ne sont tout simplement pas créés en premier lieu.

Une fois le téléchargement terminé, convertir les liens du document pour les rendre adaptés à un affichage local. Cela concerne non seulement les hyperliens visibles, mais aussi toute partie du document qui renvoie à un contenu externe, comme les images intégrées, les liens vers des feuilles de style, les hyperliens vers du contenu non HTML, etc.

Chaque lien sera changé d'une manière ou d'une autre :

  • Les liens vers les fichiers qui ont été téléchargés par wget seront modifiés pour faire référence au fichier qu'ils pointent comme lien relatif.

    Exemple : si le fichier téléchargé /toto/doc.html pointe vers /machin/img.gif aussi téléchargé, alors le lien dans doc.html sera modifié pour pointer vers ../machin/img.gif. Ce genre de transformation fonctionne pour relier des combinaisons arbitraires de répertoires.

  • Les liens des fichiers qui n'ont pas été téléchargés par wget seront modifiés pour inclure le nom d'hôte et le chemin absolu de l'emplacement vers lequel ils pointent.

    Exemple : si le fichier téléchargé /toto/doc.html pointe vers /machin/img.gif (ou vers ../machin/img.gif), alors le lien dans doc.html sera modifié pour pointer vers http://nomdhôte/machin/img.gif.

De ce fait, la navigation locale fonctionne de manière fiable : si un fichier lié a été téléchargé, le lien renverra à son nom local ; s'il n'a pas été téléchargé, le lien renverra à son adresse Internet complète plutôt que de présenter un lien brisé. Le fait que les anciens liens soient convertis en liens relatifs garantit que vous pouvez déplacer la hiérarchie téléchargée vers un autre répertoire.

Notez que ce n'est qu'à la fin du téléchargement que wget peut savoir quels liens ont été téléchargés. De ce fait, le travail effectué par -k sera réalisé à la fin de tous les téléchargements.

Cette option ne convertit que la partie nom de fichier des URL, laissant le reste des URL intactes. La partie nom de fichier réfère parfois au « nom de base », mais nous éludons ce terme ici pour ne pas créer de confusion.

Cela fonctionne particulièrement bien en conjonction avec --adjust-extension, même si ce couplage n'est pas appliqué. Cela est utile pour alimenter les caches Internet avec des fichiers téléchargés à partir de différents hôtes.

Exemple : si un lien pointe vers //toto.com/machin.cgi?xyz avec --adjust-extension activé et sa destination locale étant prévue d'être ./toto.com/machin.cgi?xyz.css, alors le lien devrait être converti en //toto.com/machin.cgi?xyz.css. Remarquez que seule la partie nom de fichier a été modifiée. Le reste de l'URL n'a pas été touché, y compris le chemin de réseau ("//") qui aurait dû autrement être traité par wget et converti en schéma effectif (c'est à dire "http://").

Lors de la conversion d'un fichier, sauvegarder la version d'origine avec un suffixe .orig. Cela a un effet sur le comportement de -N.
Activer les options adaptées à la création de miroir. Cette option active la récursion et l'horodatage, définit la profondeur à récursion infinie et garde les listes de répertoires FTP. C'est actuellement l'équivalent de -r -N -l inf --no-remove-listing.
Cette option force wget à télécharger tous les fichiers qui sont nécessaires pour afficher correctement une page HTML donnée. Cela comprend des éléments tels que les images et les sons intégrés, ainsi que les feuilles de style référencées.

Normalement, lors du téléchargement d'une seule page HTML, les documents nécessaires à son affichage ne sont pas téléchargés. Utiliser -r associé à -l peut aider, comme wget ne distingue pas d'ordinaire les documents externes de ceux internes, on se retrouve généralement avec des « documents feuilles » à qui manquent les éléments requis.

Par exemple, le document 1.html contient une étiquette "<IMG>" référençant 1.gif et une étiquette "<A>" pointant vers le document externe 2.html. Disons que 2.html est similaire mais que son image est 2.gif et qu'elle pointe vers 3.html. Disons que cela continue jusqu'à un nombre arbitrairement élevé.

Si on exécute la commande :

 wget -r -l 2 http://<site>/1.html

alors 1.html, 1.gif, 2.html, 2.gif, et 3.html seront téléchargés. Comme vous pouvez voir, 3.html est sans son requis 3.gif parce que wget compte juste le nombre de bonds (jusqu'à deux) en dehors de 1.html pour déterminer où arrêter la récursion. De toute façon, avec cette commande :

 wget -r -l 2 -p http://<site>/1.html

tous les fichiers au-dessus et le fichier 3.gif nécessaire à 3.html seront téléchargés. De même,

 wget -r -l 1 -p http://<site>/1.html

entraînera le téléchargement de 1.html, 1.gif, 2.html et 2.gif. On pourrait penser que :

 wget -r -l 0 -p http://<site>/1.html

ne téléchargera que 1.html et 1.gif, mais malheureusement ce n'est pas le cas, car -l 0 est équivalent à -l inf (qui est la récursion infinie). Pour télécharger une seule page HTML (ou une poignée d'entre elles, toutes indiquées sur la ligne de commande ou dans un fichier d'entrée -i URL ) et son (ou ses) éléments requis, enlevez simplement -r et -l :

 wget -p http://<site>/1.html

Notez que wget se comportera comme si -r avait été spécifié, mais seule cette page unique et ses éléments requis seront téléchargés. Les liens de cette page vers des documents externes ne seront pas suivis. Actuellement, pour télécharger une seule page et ses éléments requis (même s'ils existent sur d'autres sites web), et s'assurer que le lot s'affiche correctement localement, cet auteur aime utiliser quelques options en plus de -p :

 wget -E -H -k -K -p http://<site>/<document>

Pour terminer ce sujet, il est utile de savoir que l'idée que wget se fait d'un lien vers un document externe est toute URL spécifiée dans une étiquette "<A>", une étiquette "<AREA>" ou une étiquette "<LINK>" autre que "<LINK REL="stylesheet">".

Activer l'analyse stricte des commentaires HTML. Par défaut cela arrête les commentaires à la première occurrence de -->.

Selon les spécifications, les commentaires sont exprimés en tant que declarations SGML. La déclaration est un marqueur spécial commençant par <! et finissant par >, comme <!DOCTYPE...>, qui peut contenir des commentaires entre une paire de délimiteurs --. Les commentaires HTML sont des « déclarations vides », des déclarations SGML sans aucun texte qui n'est pas un commentaire. Par conséquent, <!--toto--> est un commentaire valable, et aussi <!--un-- --deux-->, mais <!--1--2--> n'en est pas un.

D'autre part, la plupart des rédacteurs de HTML ne perçoivent pas les commentaires comme autre chose que du texte délimité par <!-- et -->, ce qui n'est pas tout à fait la même chose. Par exemple, quelque chose comme <!------------> fonctionne comme un commentaire valable tant que le nombre de tirets est un multiple de quatre (!). Sinon, le commentaire dure techniquement jusqu'au prochain --, qui peut se trouver à l'autre bout du document. À cause de cela, beaucoup de navigateurs populaires ignorent totalement la spécification et mettent en œuvre ce que l'utilisateur attend : des commentaires délimités par <!-- et -->.

Jusqu'à la version 1.9, wget interprétait les commentaires de façon stricte, ce qui aboutissait en des liens manquants dans plusieurs pages web qui s'affichaient bien dans les navigateurs, mais avaient la malchance de contenir des commentaires non conformes. À partir de la version 1.9, wget a rejoint les rangs des clients qui implémentent des commentaires « naïfs », terminant chaque commentaire à la première occurrence de -->.

Si, pour une raison quelconque, vous voulez une analyse stricte des commentaires, utilisez cette option pour l'activer.

Spécifier des listes de suffixes ou de modèles de noms de fichier, séparés par des virgules, à accepter ou à rejeter. Prenez en compte que tout caractère joker *, ?, [ et ] apparaissant dans un élément de liste_acceptation ou liste_rejet sera traité comme un motif, plutôt que comme un suffixe. Dans ce cas, vous devez l'enclore de guillemets pour empêcher votre interpréteur de commande de l'étendre, comme dans -A "*.mp3" ou -A '*.mp3'.
Indiquer une expression rationnelle pour accepter ou rejeter l'URL entière
Indiquer le type d'expression rationnelle. Les types possibles sont posix ou pcre. Veuillez noter que pour pouvoir utiliser le type pcre, wget doit avoir été compilé avec la prise en charge de libpcre.
Désigner les domaines à suivre. liste_domaine est une liste de domaines séparés par des virgules. Cela n'active pas -H.
Indiquer les domaines à ne pas suivre.
Suivre les liens FTP des documents HTML. Sans cette option, wget ignorera tous les liens FTP.
wget a une table interne de paires d'étiquette/attributHTML qu'il examine lorsqu'il cherche des documents liés lors d'une récupération récursive. Cependant, si un utilisateur souhaite que seul un sous-ensemble de ces étiquettes soit pris en compte, il doit spécifier ces étiquettes dans une liste séparée par des virgules avec cette option.
C'est l'opposé de l'option --follow-tags. Pour ignorer certaines étiquettes HTML lors de la recherche récursive de documents à télécharger, indiquez-les dans une liste séparée par des virgules.

Dans le passé, cette option était la meilleure solution pour télécharger une seule page et ses éléments requis, en utilisant une ligne de commande comme :

 wget --ignore-tags=a,area -H -k -K -r
http://<site>/<document>

Cependant, l'auteur de cette option a trouvé une page avec des étiquettes comme "<LINK REL="home" HREF="/">" et a réalisé que spécifier les étiquettes à ignorer n'était pas suffisant. On ne peut pas simplement dire à wget d'ignorer "<LINK>", car les feuilles de style ne seront pas téléchargées. Maintenant la meilleure solution pour télécharger une seule page et son nécessaire reste l'option --page-requisites.

Ignorer la casse pour la correspondance des fichiers et des répertoires. Cela influence le comportement des options -R, -A, -I et -X, ainsi que le développement (globbing) mis en œuvre lors du téléchargement à partir de sites FTP. Par exemple, avec cette option, -A "*.txt" fera correspondre fichier1.txt, mais aussi fichier2.TXT, fichier3.TxT, et ainsi de suite. Les guillemets dans l'exemple sont là pour empêcher l'interpréteur de commandes de développer le motif.
Activer l'extension entre les hôtes lors de la récupération récursive.
Suivre uniquement les liens relatifs. Utile pour retrouver une page d'accueil spécifique sans aucun égarement, même pas celui dans les mêmes hôtes.
Indiquer une liste de répertoires séparés par des virgules que vous voudriez suivre lors du téléchargement. Les éléments de la liste peuvent contenir des jokers.
Indiquer une liste de répertoires séparés par des virgules que vous voudriez exclure du téléchargement. Les éléments de la liste peuvent contenir des jokers.
Ne jamais monter dans le répertoire parent lors d'une récupération récursive. C'est une option utile, vu qu'elle garantit que seuls les fichiers en dessous d'une certaine hiérarchie seront téléchargés.

wget prend en charge les mandataires à la fois pour les récupérations HTTP et FTP. La façon normale d'indiquer l'emplacement des mandataires, reconnus par wget, est d'utiliser les variables d'environnement suivantes :

Si définies, les variables http_proxy et https_proxy devraient contenir les URL des mandataires pour les connexions HTTP et HTTPS respectivement.
Cette variable devrait contenir l'URL du mandataire pour les connexions FTP. Il est assez habituel que http_proxy et ftp_proxy soient définis à la même URL.
Cette variable devrait contenir une liste de mandataires d'extensions de domaine séparées par des virgules pour lesquelles le mandataire ne devrait pas être utilisé. Par exemple, si la valeur de no_proxy est .mit.edu, le mandataire ne sera pas utilisé pour récupérer des documents de MIT.

wget peut renvoyer l'un des différents codes d'erreur s'il rencontre des problèmes.

0
Aucun problème.
1
Code d'erreur générique.
2
Erreur d'analyse - par exemple, lors de l'analyse des options de la ligne de commande, des fichiers .wgetrc ou .netrc...
3
Erreur d'entrées/sorties du fichier.
4
Échec du réseau.
5
Échec de la vérification SSL.
6
Échec de l'authentification du nom d'utilisateur ou du mot de passe.
7
Erreurs de protocole.
8
Le serveur a émis une réponse d'erreur.

À l'exception de 0 et 1, les codes de retour les moins élevés sont prioritaires par rapport aux plus élevés lorsque plusieurs types d'erreurs sont rencontrés.

Dans les versions de wget antérieures à la 1.12, les codes de retour de wget tendaient à n'être d'aucune utilité et incohérents. Les téléchargements récursifs auraient toujours renvoyé 0 (succès), sans tenir compte des problèmes rencontrés, et les recherches non récursives ne renvoyaient que l'état correspondant à la dernière tentative de téléchargement.

/etc/wgetrc
L'emplacement par défaut du fichier de démarrage global.
.wgetrc
Fichier de démarrage de l'utilisateur.

Vous êtes les bienvenus pour soumettre des rapports de bogue à l'aide du système de suivi de bogue de GNU wget (voir <https://savannah.gnu.org/bugs/?func=additem&group=wget>) ou de la liste de diffusion <bug-wget@gnu.org>.

Visitez <https://lists.gnu.org/mailman/listinfo/bug-wget> pour obtenir plus d'informations (comment souscrire, les archives de la liste, ...).

Avant de soumettre un rapport de bogue, veuillez essayer de suivre quelques principes simples.

1.
Essayez de vérifier que le comportement que vous observez est bien un bogue. Si wget se plante, c'est un bogue. Si wget ne se comporte pas comme indiqué dans la documentation, c'est un bogue. Si les choses fonctionnent bizarrement, mais que vous n'êtes pas sûr de la manière dont elles sont supposées fonctionner, cela pourrait bien être un bogue, mais vous devriez faire une double vérification dans la documentation et dans les listes de diffusion.
2.
Essayez de répéter le bogue dans des circonstances aussi simples que possible. Par exemple, si wget plante lors du téléchargement wget -rl0 -kKE -t5 --no-proxy http://example.com -o /tmp/log, vous devriez essayer de voir si le plantage est reproductible, et si cela n'arrive qu'avec un jeu d'options plus réduit. Vous pouvez même essayer de lancer le téléchargement à partir de la page où le plantage s'est produit pour voir si cette page a déclenché le plantage d'une manière ou d'une autre.

De plus, bien que je serais intéressé par le contenu de votre fichier .wgetrc, l'intégrer simplement dans le message de débogage est probablement une mauvaise idée. À la place, vous devriez d'abord essayer de voir si le bogue se répète avec un .wgetrc retiré de son emplacement. C'est seulement s'il s'avère que les paramètres de .wgetrc affectent le bogue, que vous devriez m'envoyer les parties pertinentes du fichier.

3.
Merci de démarrer wget avec l'option -d et envoyez-nous le résultat de la sortie (ou des parties pertinentes de celle-ci). Si wget a été compilé sans la gestion du débogage, recompilez-le -- il est beaucoup plus simple de suivre les bogues avec la prise en charge du débogage activée.

Note : merci de veiller à supprimer toute information potentiellement sensible du journal de débogage avant de l'envoyer à l'adresse pour les bogues. Le "-d" ne se démènera pas pour collecter des informations sensibles, mais le journal contiendra une transcription assez complète de la communication de wget avec le serveur, qui peut inclure des mots de passe et des éléments de données téléchargés. Comme l'adresse pour les bogues est publiquement archivée, vous devez comprendre que tous les rapports de bogue sont visibles du public.

4.
Si wget a planté, essayez de l'exécuter dans un outil de débogage, par exemple, "gdb `which wget` core" et tapez "where" pour en garder une sauvegarde. Cela peut ne pas fonctionner si l'administrateur système a désactivé les fichiers core, mais on peut essayer en toute sécurité.

Cela n'est pas le manuel complet de GNU wget. Pour des informations plus complètes, comprenant plus d'explications détaillées de certaines des options, et un nombre de commandes à utiliser avec les fichiers .wgetrc et l'option -e, consulter l'entrée de GNU Info pour wget.

Voir aussi wget2(1), la version mise à jour de GNU wget avec une prise en charge encore meilleure du téléchargement récursif et des protocoles modernes tels que HTTP/2.

Écrit à l'origine par Hrvoje Niki <hniksic@xemacs.org>. Actuellement maintenu par Darshit Shah <darnir@gnu.org> et Tim Rühsen <tim.ruehsen@gmx.de>.

Copyright (c) 1996--2011, 2015, 2018--2023 Free Software Foundation, Inc.

L'autorisation est accordée de copier, distribuer et/ou modifier ce document selon les termes de la GNU Free Documentation License, Version 1.3 ou toute version ultérieure publiée par la Free Software Foundation ; sans sections invariantes, sans texte de première de couverture et sans texte de couverture du verso. Une copie de la licence est incluse dans la section intitulée "GNU Free Documentation license".

La traduction française de cette page de manuel a été créée par Sébastien Blanchet, Éric Piel <eric.piel@tremplin-utc.net> et bubu <bubub@no-log.org>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.

10 septembre 2023 GNU Wget 1.21.4