Remplacement de l'utilitaire Wget par Wget2 (partie 2)

juillet

2023

17:41

Remplacement de l'utilitaire Wget par Wget2 (partie 2)

Linux

18 juillet 2023 17:41

Deuxième partie de l'article.Voir partie 1.

Options HTTP :

--default-page=name
Utilisez name comme nom de fichier par défaut lorsqu'il est inconnu (par exemple, pour les URL se terminant par une barre oblique), au lieu de index.html.

--default-http-port=port
Définissez le port par défaut pour les URL HTTP (par défaut : 80).

Utilisé principalement à des fins de tests.

--default-https-port=port
Définissez le port par défaut pour les URL HTTPS (par défaut : 443).

Utilisé principalement à des fins de tests.

-E, --adjust-extension
Si un fichier comme application/xhtml+xml ou text/html est chargé et que l'URL ne se termine pas par l'expression régulière .[Hh][Tt][Mm][Ll]?, cette option entraînera l'ajout du suffixe .html au nom du fichier local. Ceci est utile, par exemple, lorsque vous mettez en miroir un site distant qui utilise des pages .asp, mais que vous souhaitez que les pages en miroir soient visibles sur votre serveur Apache standard. Une autre bonne utilisation est lorsque vous chargez des matériaux générés par CGI. Une URL telle que https://example.com/article.cgi?25 sera enregistrée sous le nom article.cgi?25.html.

Notez que les noms de fichiers modifiés de cette manière seront retéléchargés à chaque fois que vous re-miroriserez le site, car Wget2 ne peut pas dire que le fichier local X.html correspond à l'URL distante X (puisqu'il ne sait pas encore que l'URL produit une sortie comme text/html ou application/xhtml+xml).

Wget2 garantit également que tous les fichiers texte/css téléchargés se terminent par le suffixe .css.

À un moment donné dans le futur, cette option pourrait bien être étendue pour inclure des suffixes pour d'autres types de contenu, y compris des types de contenu qui ne sont pas analysés par Wget.

--http-user=user, --http-password=password
Spécifiez un nom d'utilisateur et un mot de passe pour l'authentification HTTP. Selon le type de tâche, Wget les encodera en utilisant soit le schéma d'authentification Windows « de base » (non sécurisé), « digest » ou « NTLM ».

Si possible, mettez vos informations d'identification dans ~/.netrc (voir aussi les options --netrc et --netrc-file) ou dans .wget2rc. C'est beaucoup plus sûr que d'utiliser la ligne de commande, qui peut être vue par n'importe quel autre utilisateur. Si les mots de passe sont vraiment importants, ne les laissez pas traîner dans ces fichiers. Modifiez les fichiers et supprimez-les après le début du téléchargement de Wget2.

Dans le fichier ~/.netrc, les mots de passe peuvent être placés entre guillemets doubles pour échapper aux espaces. Échappez également les caractères avec une barre oblique inverse si nécessaire. Les barres obliques inverses dans les mots de passe doivent toujours être échappées, utilisez donc \ au lieu d'un seul .

Voir aussi --use-askpass и --ask-password pour une méthode interactive de fourniture de votre mot de passe.

--http-proxy-user=user, --http-proxy-password=password
Spécifie le nom d'utilisateur et le mot de passe pour l'authentification sur le serveur proxy HTTP. Voir pour plus de détails --http-user.

--http-proxy=proxies
Spécifie une liste de proxys HTTP séparés par des virgules. Variable d'environnement http_proxy' будет переопределена. Исключения можно установить с помощью переменной окружения no_proxy' или с помощью --no-proxy.

--https-proxy=proxies
Spécifie une liste de proxys HTTPS séparés par des virgules. Variable d'environnement https_proxy будет переопределена. Исключения можно установить с помощью переменной окружения no_proxy или с помощью --no-proxy.

--no-http-keep-alive
Désactivez le maintien en vie pour les téléchargements HTTP(S). Généralement, Wget2 demande au serveur de maintenir la connexion ouverte afin que lorsque plusieurs documents sont téléchargés depuis le même serveur, ils soient transférés via la même connexion TCP. Cela permet de gagner du temps et de réduire en même temps la charge sur le serveur.

Cette option est utile lorsque, pour une raison quelconque, les connexions persistantes ne fonctionnent pas pour vous, par exemple en raison d'un bug du serveur ou de l'incapacité des scripts du serveur à gérer les connexions.

--no-cache
Désactive le cache côté serveur. Dans ce cas, Wget2 enverra les directives appropriées (Cache-Control : no-cache et Pragma : no-cache) au serveur distant pour récupérer le fichier depuis le service distant plutôt que de renvoyer la version mise en cache. Ceci est particulièrement utile pour récupérer et nettoyer des documents obsolètes sur des serveurs proxy.
La mise en cache est activée par défaut.

--no-cookies
Désactivez l'utilisation de cookies. Les cookies sont un mécanisme côté serveur permettant de maintenir l'état. Le serveur envoie un cookie au client à l'aide de l'en-tête "Set-Cookie", et le client répond avec le même cookie à d'autres requêtes. Étant donné que les cookies permettent aux propriétaires de serveurs de suivre les visiteurs et aux sites de partager ces informations, certains les considèrent comme une violation de la vie privée. Les cookies sont utilisés par défaut ; cependant, l'enregistrement des cookies est désactivé.

--load-cookies file
Chargez les cookies d'un fichier avant la première requête HTTP(S). le fichier est un fichier texte au format utilisé à l'origine par le fichier cookie.txt de Netscape.

En règle générale, vous utiliserez cette option lors de la mise en miroir de sites qui nécessitent que vous soyez connecté pour accéder à tout ou partie de leur contenu. Le processus de connexion fonctionne généralement en demandant au serveur Web d'émettre un cookie HTTP après avoir reçu et validé vos informations d'identification. Le cookie est ensuite renvoyé par le navigateur lorsque vous accédez à cette partie du site et confirme ainsi votre identité.

La mise en miroir d'un tel site nécessite que Wget2 envoie les mêmes cookies que votre navigateur envoie lors de la communication avec le site. Ceci est réalisé en utilisant --load-cookies: Indiquez simplement à Wget2 l'emplacement du fichier cookies.txt et il enverra les mêmes cookies que votre navigateur enverrait dans la même situation. Différents navigateurs stockent les cookies texte à différents endroits :

"Netscape 4.x". Les cookies se trouvent dans ~/.netscape/cookies.txt.
"Mozilla et Netscape 6.x". Le cookie Mozilla est également appelé cookies.txt et se trouve quelque part dans le dossier ~/.mozilla de votre répertoire de profil. Le chemin complet ressemble généralement à ceci : ~/.mozilla/default/some-weird-string/cookies.txt.
"Internet Explorer". Vous pouvez créer un cookie que Wget2 peut utiliser en utilisant le menu Fichier, Importer et Exporter, Exporter les cookies. Cela a été testé avec Internet Explorer 5 ; Il n'est pas garanti qu'il fonctionne avec les versions antérieures.
"Autres navigateurs". Si vous utilisez un autre navigateur pour créer des cookies,--load-cookies ne fonctionnera que si vous pouvez trouver ou créer un cookie au format Netscape attendu par Wget2.

Si vous ne pouvez pas utiliser --load-cookies, il peut y avoir une alternative. Si votre navigateur prend en charge un « gestionnaire de cookies », vous pouvez l'utiliser pour visualiser les cookies utilisés lors de l'accès au site que vous mettez en miroir. Notez le nom et la valeur du cookie et demandez manuellement à Wget2 d'envoyer ces cookies, en contournant le support « officiel » des cookies :
wget2 --no-cookies --header "Cookie: <name>=<value>"

--save-cookies file
Enregistrez les cookies dans un fichier avant de quitter. Cela ne stockera pas les cookies expirés ou non expirés (appelés « cookies de session »), mais voyez également l'option --keep-session-cookies.

--keep-session-cookies
Lorsqu'elle est spécifiée, l'option provoque --save-cookies stocke également les cookies de session. Les cookies de session ne sont généralement pas stockés car ils sont conçus pour être stockés en mémoire et sont oubliés lorsque vous quittez le navigateur. Les enregistrer est utile sur les sites qui nécessitent de vous connecter ou de visiter la page d'accueil avant de pouvoir accéder à certaines pages. Avec cette option, plusieurs exécutions de Wget2 sont considérées comme une seule session de navigateur du point de vue du site.

Étant donné que le format de cookie ne contient généralement pas de cookies de session, Wget2 les marque avec un horodatage d'expiration de 0.
Wget2 --load-cookies распознает их как файлы cookie сеанса, но это может сбить с толку другие браузеры. Также обратите внимание, что файлы cookie, загруженные таким образом, будут рассматриваться как другие файлы cookie сеанса, а это означает, что если вы хотите, чтобы --save-cookies снова их сохраняла, вы должны снова использовать --keep-session-cookies.

--cookie-suffixes=file
Charge les suffixes publics utilisés pour la validation des cookies à partir du fichier spécifié.

Généralement, la bibliothèque principale libpsl charge ces données à partir d'un fichier système ou intègre les données. Dans certains cas, il peut être nécessaire de télécharger un fichier de suffixe public PSL mis à jour, par exemple à partir de public_suffix_list.dat

PSL vous permet d'empêcher l'installation de « super cookies » qui conduisent à des fuites de confidentialité des cookies. Plus d’informations peuvent être trouvées sur https://publicsuffix.org/.

--ignore-length
Malheureusement, certains serveurs HTTP (les programmes CGI pour être précis) envoient de faux en-têtes "Content-Length", ce qui rend Wget2 fou car il pense que l'intégralité du document n'a pas été reçu. Vous remarquerez peut-être ce syndrome si Wget essaie de récupérer le même document encore et encore, affirmant à chaque fois que la connexion (par ailleurs normale) a été fermée sur le même octet.

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

--header=header-line
Envoyez la ligne d'en-tête avec les autres 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 deux points et ne doit pas contenir de nouvelles lignes.

Vous pouvez définir plusieurs en-têtes supplémentaires en spécifiant –header plusieurs fois.
wget2 --header='Accepter-Charset : iso-8859-2' \ --header='Accepter-Langue : hr' \ https://exemple.com/

Spécifier une chaîne vide comme valeur d'en-tête effacera les en-têtes précédents définis par l'utilisateur.

Cette option peut être utilisée pour remplacer les en-têtes qui seraient autrement générés automatiquement. Cet exemple indique à Wget2 de se connecter à localhost, mais spécifie exemple.com dans l'en-tête « Host » :

wget2 --header="Host: example.com" http://localhost/

--max-redirect=number
Spécifiez le nombre maximum de redirections pour la ressource. La valeur par défaut est 20, ce qui est généralement beaucoup plus élevé que nécessaire. Cependant, dans les cas où vous souhaitez autoriser plus (ou moins), vous pouvez utiliser cette option.

--proxy-user=user, --proxy-password=password(Non implémenté, utilisez --http-proxy-password).
Spécifiez l'utilisateur de connexion et le mot de passe pour l'authentification sur le serveur proxy. Wget2 les encodera en utilisant un schéma d'authentification "de base".
Les considérations de sécurité telles que celles affectant --http-password, postulez également ici.

--referer=url
Inclut l'en-tête « Referer : url » dans la requête HTTP. Utile pour récupérer des documents avec un traitement côté serveur en supposant qu'ils sont toujours récupérés par des navigateurs Web interactifs et rendus correctement uniquement si le référent est défini sur l'une des pages pointant vers eux.

--save-headers
Enregistrez les en-têtes envoyés par le serveur HTTP avant le contenu réel dans un fichier avec une ligne vide comme délimiteur.

-U agent-string, --user-agent=agent-string
Identifiez-vous sur le serveur HTTP à l'aide de la ligne suivante « User-Agent ».

Le protocole HTTP permet aux clients de s'identifier à l'aide d'un champ d'en-tête « User-Agent ». Cela permet de différencier les logiciels WWW, généralement à des fins statistiques ou pour suivre les violations de protocole. Wget est généralement identifié comme Wget/version, où version est le numéro de version actuel de Wget.

Cependant, certains sites sont connus pour imposer une politique d'adaptation du rendu en fonction des informations fournies par le « User-Agent ». Bien que ce ne soit pas une si mauvaise idée en théorie, elle a été utilisée à mauvais escient par des serveurs refusant des informations à des clients autres que (historiquement) Netscape ou, plus communément, Microsoft Internet Explorer. Cette option permet de modifier la chaîne "User-Agent" renvoyée par Wget. L'utilisation de cette option n'est pas recommandée, sauf si vous savez vraiment ce que vous faites.

--post-data=string, --post-file=file
Utilisez POST comme méthode pour toutes les requêtes HTTP et envoyez les données spécifiées dans le corps de la requête.--post-data отправляет строку в виде данных, тогда как --post-file envoie le contenu du fichier. Sinon, ils fonctionnent exactement de la même manière.

Plus précisément, les deux paramètres attendent un contenu sous la forme « key1=value1&key2=value2 » avec un codage en pourcentage pour les caractères spéciaux.
La seule différence est que l'un attend son contenu comme paramètre de ligne de commande, tandis que l'autre accepte son contenu à partir d'un fichier. En particulier, --post-file n'est pas destiné à transmettre des fichiers sous forme de pièces jointes de formulaire : ils doivent apparaître sous forme de données clé=valeur (avec un codage en pourcentage approprié), comme tout le reste.

Actuellement, Wget2 ne prend pas en charge « multipart/form-data » pour le transfert de données POST ; uniquement "application/x-www-form-urlencoded". Un seul des paramètres doit être précisé :--post-data или --post-file.

Notez que wget2 n'exige pas que le contenu soit "key1=value1&key2=value2" et ne le vérifie pas. Wget2 transmettra simplement toutes les données qui lui seront fournies. Cependant, la plupart des serveurs s'attendent à ce que les données POST soient au format ci-dessus lors du traitement des formulaires HTML.

Lors de l'envoi d'une requête POST à l'aide du paramètre --post-file wget2 traite le fichier comme un fichier binaire et enverra chaque caractère de la requête POST sans supprimer les nouvelles lignes ou les sauts de page. Tous les autres caractères de contrôle dans le texte seront également envoyés tels quels dans la requête POST.

ИмеGardez à l’esprit que Wget2 doit connaître à l’avance la taille des données POST. C'est pourquoi l'argument --post-file doit être un fichier régulier ; spécifier FIFO ou quelque chose comme /dev/stdin ne fonctionnera pas. Il n’est pas tout à fait clair comment contourner cette limitation inhérente à HTTP/1.0. Bien que HTTP/1.1 ait introduit des transferts fragmentaires qui ne nécessitent pas de connaissance préalable de la longueur de la requête, un client ne peut pas utiliser ce transfert à moins de savoir qu'il communique avec un serveur HTTP/1.1. Et il ne peut pas le savoir jusqu'à ce qu'il reçoive une réponse, qui, à son tour, nécessite de répondre à la demande - le « problème de la poule et de l'œuf ».

Si Wget2 redirige une fois la requête POST terminée, son comportement dépend du code de réponse renvoyé par le serveur. Dans le cas de « 301 définitivement déplacé », « 302 temporairement déplacé » ou « 307 temporairement redirigé », Wget2 continuera à envoyer la requête POST conformément à la RFC2616. Si le serveur souhaite que le client change la méthode de requête lors de la redirection, il doit envoyer un code de réponse « 303 See Other ».

Cet exemple montre comment se connecter au serveur à l'aide de POST, puis procéder au chargement des pages souhaitées, vraisemblablement accessibles uniquement aux utilisateurs autorisés :
#Connectez-vous au serveur. Cela ne peut être fait qu'une seule fois. wget2 --save-cookies cookies.txt \ --post-data 'user=foo&password=bar' \ http://exemple.com/auth.php #Maintenant, nous capturons la ou les pages qui nous intéressent. wget2 --load-cookies cookies.txt \ -p http://exemple.com/interesting/article.php
Si le serveur utilise des cookies de session pour suivre l'authentification des utilisateurs, ce qui précède ne fonctionnera pas car --save-cookies не сохранит их (как и браузеры), а файл cookies.txt будет пустым. В этом случае используйте ---keep-session-cookies вместе с опцией --save-cookies pour forcer l'enregistrement des cookies de session.

--method=HTTP-Method
Pour les scénarios RESTful, Wget2 vous permet d'envoyer d'autres méthodes HTTP sans avoir à les définir explicitement avec --header=Header-Line. Wget2 будет использовать любую строку, переданную ему после --method, comme méthode HTTP pour le serveur.

--body-data=Data-String, --body-file=Data-File
Cette option doit être définie lorsque des données supplémentaires doivent être envoyées au serveur avec la méthode spécifiée avec l'option --method. Ключ --body-data отправляет строку как данные, а --body-file envoie le contenu du fichier. Sinon, ils fonctionnent exactement de la même manière.

Actuellement option --body-file не предназначена для передачи файлов целиком. В настоящее время Wget2 не поддерживает «multipart/form-data» для передачи данных; только «application/x-www-form-urlencoded». В будущем это может быть изменено, чтобы wget2 отправлял --body-file как полный файл, а не отправлял его содержимое на сервер. Имейте в виду, что Wget2 необходимо заранее знать содержимое BODY Data, поэтому аргумент --body-file должен быть обычным файлом. См. --post-file для более подробного объяснения. Должен быть указан только один из --body-data и --body-file.

Si Wget2 redirige une fois la requête terminée, Wget2 met en pause la méthode actuelle et envoie une requête GET jusqu'à ce que la redirection soit terminée. Cela est vrai pour tous les codes de réponse de redirection, à l'exception de 307 Temporary Redirect, qui est utilisé pour indiquer explicitement que la méthode de requête ne doit pas être modifiée. Une autre exception est lorsque la méthode est définie sur "POST", auquel cas les règles de redirection spécifiées dans le paramètre sont suivies.--post-data.

--content-disposition
Lorsqu'elle est activée, la prise en charge expérimentale (pas entièrement fonctionnelle) des en-têtes « Content-Disposition » est activée. Cela peut actuellement entraîner des accès supplémentaires au serveur pour la requête "HEAD" et est connu pour souffrir de plusieurs bugs, il n'est donc pas actuellement activé par défaut.

Cette option est utile pour certains programmes CGI qui chargent des fichiers, qui utilisent les en-têtes "Content-Disposition" pour décrire le nom du fichier chargé.

--content-on-error
Si cette option est activée, wget2 ne transmettra pas le contenu lorsque le serveur répond avec un code d'état http indiquant une erreur.

--save-content-on
Après le signe égal, vous devez spécifier une liste de codes d'état HTTP, séparés par des virgules, dans lesquels le contenu sera enregistré.

Vous pouvez utiliser « * » pour TOUT. Un point d'exclamation (!) devant le code signifie "exception".

Exemple 1 :--save-content-on="*,!404" enregistrera le contenu avec tous les codes d'état HTTP autres que 404.

Exemple 2 :--save-content-on=404 n'enregistrera que le contenu avec un code d'état HTTP de 404.

Option plus ancienne --content-on-error действует так же, как --save-content-on=*.

--trust-server-names
Si ce paramètre est activé, le dernier composant de l'URL de redirection sera utilisé comme nom de fichier local lors de la redirection. Par défaut, le dernier composant de l'URL source est utilisé.

--auth-no-challenge
Si ce paramètre est spécifié, Wget2 enverra des informations d'authentification HTTP de base (nom d'utilisateur et mot de passe non chiffrés) pour toutes les requêtes.

L'utilisation de cette option n'est pas recommandée et est uniquement destinée à prendre en charge certains serveurs obscurs qui n'envoient jamais de requêtes d'authentification HTTP, mais acceptent des informations d'authentification non sollicitées, par exemple, en plus de l'authentification basée sur des formulaires.

--compression=TYPE
Si ce TYPE de compression est spécifié (identity, gzip, deflate, xz, lzma, br, bzip2, zstd, lzip ou toute combinaison de ceux-ci), Wget2 définira l'en-tête "Accept-Encoding" en conséquence. --no-compression signifie qu'il n'y a aucun en-tête "Accept-Encoding". Pour définir une valeur "Accept-Encoding" personnalisée, utilisez --no-compression в сочетании с --header="Accept-Encoding: xxx".

Note de compatibilité : Wget 1.X n'a pas les moyens de spécifier le type de compression que Wget2.

--download-attr=[strippath|usepath]
L'attribut de téléchargement HTML5 peut spécifier (ou mieux : suggérer) le nom de fichier à partir de l'URL href dans les balises "a" et "area". Cette option indique à Wget2 d'utiliser ce nom lors de l'enregistrement du fichier. Deux valeurs possibles : `strippath' pour supprimer le chemin du nom de fichier. Il s'agit de la valeur par défaut.

Signification usepath accepte un nom de fichier incluant un répertoire. C'est très dangereux et nous ne pouvons pas l'utiliser sans souci sur des entrées ou des serveurs non fiables ! Utilisez-le uniquement si vous faites vraiment confiance à l'entrée ou au serveur.

Options HTTPS (SSL/TLS)

Pour prendre en charge les téléchargements cryptés HTTP (HTTPS), Wget2 doit être compilé avec la prise en charge d'une bibliothèque SSL externe. Actuellement, GnuTLS est utilisé par défaut. De plus, Wget2 prend également en charge HSTS (HTTP Strict Transport Security). Si Wget2 est compilé sans support SSL, aucune de ces options n'est disponible.

--secure-protocol=protocol
Sélectionnez le protocole sécurisé à utiliser (par défaut : auto).

Valeurs autorisées auto, SSLv3, TLSv1, TLSv1_1, TLSv1_2, TLSv1_3 и PFS.

Si utilisé auto, le mode bibliothèque TLS par défaut est appliqué.

УкаConnaître SSLV3 vous oblige à utiliser SSL3. Ceci est utile lorsqu'il s'agit d'implémentations de serveur SSL plus anciennes et boguées qui ont du mal à sélectionner correctement la version du protocole TLS à l'aide de la bibliothèque TLS sous-jacente.

La spécification de PFS garantit la conformité avec les ensembles dits Perfect Forward Security. En bref, PFS ajoute la sécurité de générer une clé unique pour chaque connexion TLS. Ce qui met un peu plus de pression sur le CPU du client et du serveur. Nous sommes familiers avec les chiffrements sécurisés (par exemple, sans MD4) et le protocole TLS.

TLSV1 active TLS1.0 ou version ultérieure. TLSV1_1 active TLS1.1 ou version ultérieure. TLSV1_2 active TLS1.2 ou supérieur. TLSV1_3 active TLS1.3 ou version ultérieure.

Toute autre chaîne de protocole est transmise directement à la bibliothèque TLS, actuellement Gnutls, en tant que chaîne de « priorité » ou de « chiffre ».
Cette option est destinée aux utilisateurs qui comprennent ce qu’ils font.

--https-only
En mode récursion, le programme suivra uniquement les liens HTTPS.

--no-check-certificate
Ne comparez pas le certificat du serveur aux autorités de certification disponibles. Peut également être utilisé si le nom de l'URL de l'hôte ne correspond pas au nom commun représenté par le certificat.

Par défaut, la vérification du certificat du serveur est effectuée auprès des autorités de certification, ce qui interrompt la négociation SSL et interrompt le démarrage si la vérification du certificat échoue. Bien que cela fournisse des téléchargements plus sécurisés, cela rompt la compatibilité avec certains sites qui fonctionnaient avec les versions précédentes de WGET, en particulier ceux qui utilisent des certificats auto-signés, expirés ou non valides. Cette option force un mode de fonctionnement « non sécurisé », qui transforme les erreurs de vérification du certificat en avertissements et vous permet de continuer.

Si vous rencontrez des erreurs de « vérification du certificat » ou mentionnez que « le nom commun ne correspond pas au nom d'hôte demandé », vous pouvez utiliser cette option pour contourner la vérification et poursuivre le téléchargement. N'utilisez cette option que si vous êtes convaincu de l'authenticité du site, ou si vous ne vous souciez vraiment pas de la validité de son certificat. C'est presque toujours une mauvaise idée de ne pas vérifier les certificats lors du transfert de données sensibles ou importantes. Pour moi

Certificats auto-signés/internes : vous devez télécharger le certificat et le vérifier au lieu de forcer ce mode non sécurisé. Si vous êtes vraiment sûr de ne vouloir aucune vérification de certificat, vous pouvez spécifier --check-certificate=quiet pour dire à WGET2 de ne pas imprimer d'avertissements concernant les certificats invalides, bien que cela soit incorrect dans la plupart des cas.

--certificate=file
Utilisez le certificat client stocké dans le fichier. Cette option est requise pour les serveurs configurés pour exiger des certificats des clients qui s'y connectent. En règle générale, aucun certificat n'est requis et ce commutateur est facultatif.

--certificate-type=type
Indique le type de certificat client. Les valeurs perçues sont PEM (par défaut) ou DER, également appelées ASN1.

--private-key=file
Lire une clé privée à partir d'un fichier. Cette option permet de fournir la clé privée dans un fichier distinct du certificat.

--private-key-type=type
Spécifiez le type de clé privée. Valeurs perçues de PEM (par défaut) et DER.

--ca-certificate=file
Utilisez un fichier qui stocke un ensemble de certificats d'autorité de certification (« CA ») pour vérifier les parties. Les certificats doivent être au format PEM.

Sans cette option spécifiée, Wget2 recherche les certificats CA dans les emplacements système (dossiers) sélectionnés lors de l'installation d'OpenSSL.

--ca-directory=directory
Spécifie le répertoire contenant les certificats de l'autorité de certification (CA) au format PEM. Chaque fichier contient un certificat d'autorité de certification (CA) et le nom du fichier est dérivé de la valeur de hachage de ce fichier de certificat. Ceci est réalisé en traitant le répertoire des certificats avec l'utilitaire "C_REHASH" fourni avec OpenSSL. L'utilisation de --ca-directory est plus efficace que --ca-certificate lorsque de nombreux certificats sont installés car elle permet à WGET2 d'obtenir des certificats à la demande.

Sans cette option, WGET2 recherche les certificats CA dans les emplacements système sélectionnés lors de l'installation d'OpenSSL.

--crl-file=file
Spécifie le fichier de révocation de certificat (CRL). Il est obligatoire d'indiquer les certificats qui ont été révoqués par les autorités de certification (AC).

--random-file=file
(Uniquement pour OpenSSL et LibreSSL). Utilisez le fichier comme source de données aléatoires pour les graines du générateur de nombres pseudo-aléatoires sur un système sans le périphérique /dev/urandom.

Sur de tels systèmes, la bibliothèque SSL nécessite une source externe de caractère aléatoire pour l'initialisation. Le caractère aléatoire peut être fourni par l'EGD (voir –EGD ci-dessous) ou lu à partir d'une source externe spécifiée par l'utilisateur. Si cette option n'est pas spécifiée, WGET2 recherche des données aléatoires dans $randfile ou, si celle-ci est incorrecte, dans $home/.rnd.

Si vous obtenez l'erreur "Impossible d'amorcer OpenSSL PRNG ; désactivation de SSL.", vous devez fournir des données aléatoires en utilisant certaines des méthodes décrites ci-dessus.

--egd-file=file
[OpenSSL uniquement] Utilisez le fichier comme socket EGD. L'acronyme 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 permet à d'autres programmes utilisant le cryptage d'utiliser l'entropie, comme la bibliothèque SSL, qui nécessite des sources de valeurs aléatoires non répétitives pour amorcer le générateur de nombres aléatoires utilisé pour créer des clés cryptographiquement fortes.

OpenSSL permet à l'utilisateur de spécifier sa propre source d'entropie à l'aide de la variable d'environnement "RAND_FILE". Si cette variable n'est pas définie, ou si le fichier spécifié ne fournit pas suffisamment de caractère aléatoire, OpenSSL lira les données aléatoires du Socket EGD spécifié à l'aide de cette option.

Si cette option n'est pas spécifiée (et que la commande d'exécution équivalente n'est pas utilisée), EGD n'est jamais associé. EGD n'est pas requis sur les systèmes UNIX modernes prenant en charge /dev/urandom.

--hsts
WGET2 prend en charge HSTS (HTTP Strict Transport Security, RFC 6797) par défaut. Utilisez --no-hsts pour forcer WGET2 à agir en tant qu'agent utilisateur non compatible HSTS. En conséquence, WGET2 ignorera tous les en-têtes « Strict-Transport-Security » et n'appliquera aucune politique HSTS existante.

--hsts-file=file
Par défaut, WGET2 stocke ses données HSTS dans $xdg_data_home/wget/.wget-hsts ou, si xdg_data_home n'est pas défini, dans ~/.lo-cal/wget/.wget-hsts. Vous pouvez utiliser --hsts-file pour remplacer cela.

WGET2 utilisera le fichier fourni comme base de données HSTS. Un tel fichier doit être conforme au format de base de données HSTS correct utilisé par WGET. Si WGET2 ne peut pas analyser le fichier fourni, le comportement n'est pas défini.

Pour désactiver le stockage persistant, utilisez --no-hsts-file.

La base de données Wget2 HSTS est un simple fichier texte. Chaque ligne contient une entrée HSTS (c'est-à-dire le site qui a émis l'en-tête « Strict-Transport-Security » et a donc spécifié la politique HSTS spécifique à appliquer). Lignes commençant par un tiret ("#"), sont ignorés par Wget. Veuillez noter que malgré cette forme lisible par l'homme, corriger manuellement la base de données HSTS n'est généralement pas une bonne idée.

La ligne de saisie HSTS est composée de plusieurs champs séparés par un ou plusieurs espaces :

имя_хоста ПРОБЕЛ порт ПРОБЕЛ включать_поддомены ПРОБЕЛ создано ПРОБЕЛ максимальный_возраст

ПолLe nom d'hôte et le port spécifient le nom d'hôte et le port auxquels cette stratégie HSTS s'applique. Le champ "port" peut être vide, et le sera dans la plupart des cas. Cela signifie que le numéro de port ne sera pas pris en compte pour décider si cette politique HSTS doit être appliquée à une requête donnée (seul le nom d'hôte sera évalué). Lorsque le port n'est pas vide, le nom d'hôte cible et le port seront évalués, et la stratégie HSTS ne sera appliquée que si le port de l'hôte et le port du fichier correspondent. Cette fonctionnalité a été activée uniquement à des fins de test/développement. TestSuite WGET2 (dans TestenV/) crée des bases de données HSTS avec des ports explicites pour garantir un comportement correct de Wget2. Application des politiques HSTS aux ports autres que ceux par défaut, RFC 6797 (voir Annexe B, « Différences entre la « politique HSTS et la politique de même origine »). Par conséquent, cette fonctionnalité ne doit pas être utilisée dans des environnements de production et le port sera généralement vide.

Les trois derniers champs font ce que l'on attend d'eux. Le champ « include_subdomains » peut être 1 ou 0, et il indique si les sous-domaines du domaine cible doivent également faire partie de cette politique HSTS. Les champs "created" et "max_age" contiennent l'horodatage de la création de l'enregistrement (vu pour la première fois par WGET) et la valeur définie par HSTS.max-age, qui indique la durée pendant laquelle cette stratégie HSTS reste active, mesurée en secondes depuis la création du dernier horodatage, qui est stockée dans le champ « créé ». Une fois ce délai passé, cette politique HSTS ne sera plus valide et sera éventuellement supprimée de la base de données.

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

Si le fichier fourni n'existe pas, WGET2 le créera. Ce fichier contiendra les nouveaux enregistrements HSTS. Si aucun enregistrement HSTS n'a été généré (aucun en-tête « Strict-Transport-Security » n'a été envoyé par aucun des serveurs), alors le fichier ne sera pas créé, même s'il est vide. Ce comportement s'applique au fichier de base de données par défaut (~/.wget-HSTS) : il ne sera pas créé tant qu'un serveur n'aura pas appliqué la stratégie HSTS.

Veillez à ne pas remplacer les éventuelles modifications apportées par d'autres processus WGET2 en même temps à la base de données HSTS. Avant de vider les entrées HSTS mises à jour dans un fichier, WGET2 le relit et fusionne les modifications.

Utiliser une base de données HSTS personnalisée et/ou modifier une base de données existante. Pour plus d'informations sur les risques de sécurité potentiels découlant de cette pratique, consultez la section 14, « Considérations sur la sécurité » de la RFC 6797, en particulier la section 14.9, « Manipulation créative de l'ensemble de stratégies HSTS ».

--hsts-preload
Permet le chargement de la liste de préchargement HSTS selon le support de libhsts. (Par défaut : activé si construit avec Libhsts).

--hsts-preload-file=file
Si Wget2 est construit avec le support de libhsts, WGET2 utilise les données HSTS fournies par le programme d'installation. S'il n'est pas inclus dans la distribution ou si vous souhaitez télécharger votre propre fichier, utilisez cette option.

Les données de ce fichier doivent être au format DAFSA tel que généré par le programme libhsts du package hsts-make-dafsa.

--hpkp
Activez l'épinglage de clé publique HTTP (HPKP) (par défaut : activé).

Ce mécanisme de confiance à la première utilisation (TOFU) ajoute une autre couche de sécurité à HTTPS (voir RFC 7469).

Les données de clé de certificat de la session TLS précédemment établie seront comparées aux données actuelles. Si les deux ne correspondent pas, la connexion sera interrompue.

--hpkp-file=file
Par défaut, WGET2 stocke ses données HPKP dans $ xdg_data_home/wget/.wget-hpkp ou, si xdg_data_home n'est pas défini, dans ~/.lo-cal/wget/.wget-hpkp. Vous pouvez utiliser --hpkp-file pour remplacer ce comportement.

WGET2 utilisera le fichier spécifié comme base de données HPKP. Un tel fichier doit être conforme au format de base de données HPKP correct utilisé
Wget. Si WGET2 ne peut pas analyser le fichier fourni, le comportement n'est pas défini.

Pour désactiver le stockage, utilisez --no-hpkp-file.

--tls-resume
Activez la reprise de session TLS, qui est désactivée par défaut.

Pour reprendre une session TLS, les données d'une session TLS précédemment établie sont requises.

Il existe plusieurs failles de sécurité associées à la reprise de session TLS 1.2, qui sont expliquées en détail à l'adresse.

--tls-session-file=file
Par défaut, Wget2 stocke ses données de session TLS dans $xdg_data_home/wget/.wget-session ou, si xdg_data_home n'est pas défini, dans
~/.local/wget/.wget-session. Vous pouvez utiliser --tls-session-file pour le remplacer.

WGET2 utilisera le fichier spécifié comme base de données de session TLS. Un tel fichier doit être conforme au format de base de données de session TLS correct utilisé par WGET. Si WGET2 ne peut pas analyser le fichier fourni, le comportement n'est pas défini.

Pour désactiver le stockage persistant, utilisez --no-tls-session-file.

--tls-false-start
Activez le faux départ TLS (par défaut : activé).

Cette option réduit les négociations TLS d'un aller-retour et accélère ainsi les connexions HTTPS.

Plus d'informations sur https://tools.ietf.org/html/rfc7918.

--check-hostname
Activez la vérification TLS SNI (Server Name Indication) (par défaut : activé).

--ocsp
Activez l'accès OCSP au serveur pour vérifier si les certificats HTTPS du serveur peuvent être révoqués (par défaut : activé).

Cette procédure est assez lente (connexion au serveur, requête HTTP, réponse) et nous prenons donc en charge l'agrafage OSCP (le serveur envoie une réponse OCSP lors de la prise de contact TLS) et fournissons une mise en cache OCSP persistante.

--ocsp-date
Vérifiez que la réponse OCSP est trop ancienne. (par défaut : activé)

--ocsp-nonce
Autoriser la vérification occasionnelle lors de la validation d'une réponse OCSP. (par défaut : activé)

--ocsp-server
Spécifiez l'adresse du serveur OCSP (par défaut : serveur OCSP spécifié dans le certificat).

--ocsp-stapling
Activez la prise en charge de l'agrafage OCSP (par défaut : activé).

--ocsp-file=file
Par défaut, WGET2 stocke ses données de session TLS dans $xdg_data_home/wget/.wget-ocsp или, если xdg_data_home не установлен, в ~/.local/wget/.wget-ocsp. Вы можете использовать --ocsp-file pour remplacer cela.

WGET2 utilisera le fichier spécifié comme base de données OCSP. Un tel fichier doit être conforme au format de base de données OCSP correct utilisé par WGET. Si WGET2 ne peut pas analyser le fichier fourni, le comportement n'est pas défini.

Pour désactiver la mise en cache OCSP persistante, utilisez --no-ocsp-file.

--dane(fonctionnalité expérimentale)
Activer la prise en charge de la vérification du certificat DANE (par défaut : désactivé).

Dans le cas où la vérification du serveur échoue en raison de certificats d'autorité de certification manquants (par exemple, un pool de certification vide), cette option permet la vérification des enregistrements DNS TLSA via DANE.

Vous devez installer DNSSEC pour éviter les attaques MITM. De plus, les enregistrements d'hôte DNS de destination doivent être configurés pour DANE.

Attention : Cette option ou son comportement peut changer ou être supprimé sans préavis.

--http2
Activez la prise en charge du protocole HTTP/2 (par défaut : activé).

Wget2 demande HTTP/2 via ALPN. S'il est disponible, il l'utilise à la place de HTTP/1.1. Jusqu'à 30 threads sont utilisés en parallèle au sein d'une seule connexion.

--http2-only

Résistez et utilisez uniquement les connexions HTTP/2 et génèrez une erreur si le serveur ne l'accepte pas. Principalement pour tester.

--https-enforce=mode
Définit comment gérer les URL pour lesquelles aucun schéma explicite n'est spécifié (ceux avec un schéma autre que https://) (mode par défaut : aucun)

mode=none
Utilisez le mode HTTP dans les URL sans schéma. L'opération récursive utilisera le schéma du document parent.

mode=soft
Essayez d'abord HTTPS si le schéma HTTP n'est pas spécifié. S'il y a une erreur, revenez au HTTP de sauvegarde.

mode=hard
Utilisez uniquement HTTPS, que le schéma HTTP soit spécifié ou non. Ne revenez pas au HTTP de secours.

Options du plugin

--list-plugins
Imprimez une liste de tous les plugins disponibles et quittez.

--local-plugin=file
Téléchargez le fichier en tant que plugin.

--plugin=name
Chargez un plugin avec le nom spécifié à partir des répertoires de plugins spécifiés dans la configuration.

--plugin-dirs=directories
Configurez les répertoires de plugins. Les répertoires de plugins dans la liste sont séparés par des virgules.

--plugin-help
Imprimez l'aide pour tous les plugins téléchargés.

--plugin-opt=option
Spécifier les paramètres spécifiques au plugin

Les paramètres du plugin "option" sont spécifiés au format <plugin_name>.<option>[=value].

Environnement : serveurs proxy

Wget2 prend en charge les proxys de récupération sur les deux protocoles, HTTP et HTTPS. La manière standard de spécifier un emplacement proxy reconnu par WGET consiste à utiliser les variables d'environnement suivantes :

http_proxy
https_proxy

Si elles sont spécifiées, les variables http_proxy et https_proxy doivent contenir respectivement les URL proxy pour les connexions HTTP et HTTPS.

no_proxy

Cette variable doit contenir une liste de domaines séparés par des virgules pour lesquels les proxys ne doivent pas être utilisés. Par exemple, si la valeur de no_proxy est .example.com, le proxy ne sera pas utilisé pour récupérer les documents de *.example.com.

Codes d'achèvement

WGET2 peut renvoyer l'un des nombreux codes d'erreur s'il rencontre des problèmes.

0, il n'y a eu aucun problème.
1 code d'erreur général.
2 erreur d'analyse. Par exemple, une erreur lors de l'analyse des paramètres de ligne de commande ou des fichiers .wget2rc ou .netrc...
3 erreur d'entrée/sortie de fichier.
4 panne de réseau.
5 La vérification SSL a échoué.
6 L'authentification par nom d'utilisateur/mot de passe a échoué.
7 erreur de protocole.
8 Le serveur a répondu avec un code d'erreur.
9 La clé publique est manquante dans Keyring.
10 La vérification de la signature a échoué.

À l'exception de 0 et 1, les codes de sortie à faible numéro ont priorité sur ceux à numéro plus élevé lorsque plusieurs types d'erreur sont rencontrés.

Fichier de lancement

Вы Vous souhaiterez peut-être modifier définitivement le comportement par défaut de GNU WGET2. Il existe une meilleure façon de procéder qu'en définissant un alias de commande dans votre shell. GNU WGET2 vous permet de définir tous les paramètres de manière permanente via son fichier de démarrage .WGET2RC.

Bien que .WGET2RC soit le principal fichier d'initialisation utilisé par GNU WGET2, ce n'est pas une bonne idée de stocker les mots de passe dans ce fichier.
En effet, le fichier de démarrage peut être lisible publiquement ou archivé sous contrôle de version. C'est pourquoi WGET2 lit également le contenu du fichier $Home/.NETRC en cas de besoin.

Le fichier .WGET2RC suit une syntaxe très similaire à .WGETRC, qui est lu par GNU WGET. Cela ne diffère que dans les endroits où les options de ligne de commande varient entre wget1.x et wget2.

Emplacement de Wget2rc

Une fois initialisé, WGET2 tentera de lire le fichier de démarrage « global », qui se trouve par défaut dans /usr/local/etc/wget2rc' (или какой -то префикс, отличный от/usr/local' si Wget2 n'y était pas installé). Le fichier de démarrage global est utile aux administrateurs système pour appliquer les politiques par défaut telles que la définition du chemin du magasin de certificats, le préchargement de la liste HSTS, etc.

Wget2 recherchera alors le fichier d'initialisation de l'utilisateur. Si l'utilisateur a utilisé l'option de ligne de commande --config wget2 essaiera de télécharger le fichier vers lequel il pointe. Si le fichier n'existe pas ou s'il ne peut pas être lu, WGET2 ne tentera plus de lire les fichiers d'initialisation.

Si la variable d'environnement WGET2RC est définie, WGET2 tentera de télécharger le fichier à partir du chemin spécifié. Si le fichier n'existe pas ou s'il ne peut pas être lu, WGET2 ne tentera plus de lire le fichier d'initialisation.

Si -config échoue et que WGET2RC n'est pas installé, WGET2 tentera de charger le fichier d'initialisation utilisateur à partir de l'emplacement tel que défini dans la spécification du répertoire de base XDG. Il lira le premier et uniquement le premier fichier qu'il trouvera aux emplacements suivants :

1.$XDG_CONFIG_HOME/wget/wget2rc

2.$HOME/.config/wget/wget2rc

3.$HOME/.wget2rc

L'emplacement du fichier d'initialisation dans $home/.wget2rc est obsolète. Si un fichier y est trouvé, WGET2 affichera un avertissement à ce sujet. La prise en charge de la lecture de ce fichier sera supprimée à l'avenir.

Le fait que les paramètres utilisateur soient chargés après le paramètre global signifie qu'en cas de conflit, le WGET2RC de l'utilisateur remplacera le WGET2RC global.

Erreurs

Vous pouvez soumettre des rapports de bogues via The Gnu Wget2 Tracker (https://gitlab.com/gnuwget/wget2/issues).

Avant de soumettre un rapport de bug, essayez de suivre quelques directives simples.

Veuillez essayer de découvrir que le comportement que vous constatez est en fait un bug. Si Wget2 plante, c'est une erreur. Si Wget2 ne se comporte pas comme indiqué, c'est un bug. Si les choses fonctionnent étrangement mais que vous n'êtes pas sûr de la manière dont elles sont censées fonctionner, cela pourrait très bien être un bug, mais vous souhaiterez peut-être revérifier la documentation et les listes de diffusion.
Essayez de reproduire l'erreur dans les circonstances les plus simples possibles. Par exemple. Si WGET2 plante lors du chargement de WGET2 -RL0 -KKE -T5 --no-proxy https://example.com -o/tmp/log, vous devriez essayer de voir si le crash se reproduit et se produira avec un ensemble d'options plus simple. Vous pouvez même essayer de démarrer le chargement sur la page sur laquelle le crash s'est produit pour voir si cette page a provoqué le crash d'une manière ou d'une autre.

De plus, même si je serais probablement intéressé de connaître le contenu de votre fichier .WGET2RC, le simple fait de le transférer dans un message de débogage est probablement une mauvaise idée. Au lieu de cela, vous devriez d'abord essayer de voir si l'erreur se reproduit si .WGET2RC s'écarte. Seulement s'il s'avère que les paramètres .wget2rc contribuent à l'erreur, veuillez m'envoyer par e-mail les parties pertinentes du fichier.

Veuillez exécuter wget2 avec l'option -d et envoyez-nous le résultat obtenu (ou les parties pertinentes de celui-ci). Si Wget2 a été compilé sans prise en charge du débogage, recompilez-le. Il est beaucoup plus facile de suivre les erreurs en utilisant le débogage.

NOTE. Assurez-vous de supprimer toute information potentiellement sensible du journal de débogage avant de le soumettre à l'adresse du bogue. -D ne fera pas tout son possible pour collecter des informations sensibles, mais le journal contiendra une transcription assez complète de la communication de Wget2 avec le serveur, qui peut inclure des mots de passe et des parties des données téléchargées. Puisque l'adresse du bug est publique, vous pouvez supposer que tous les rapports de bugs sont visibles par le public.

Si Wget2 est cassé, essayez de l'exécuter dans un débogueur comme GDB What Wget core et entrez "où" pour obtenir le Backtrace. Cela peut ne pas fonctionner si l'administrateur système a désactivé les fichiers principaux, mais vous pouvez essayer en toute sécurité.

Auteur

Wget2, écrit par Tim Ruehsen tim.ruehsen@gmx.de
Wget 1.x, écrit à l'origine par Hrvoje Nikthić hniksic@xemacs.org

Droit d'auteur

L'autorisation est accordée de copier, distribuer et/ou modifier ce document selon les termes de la licence GNU, version 1.3 ou toute version ultérieure publiée par la Free Software Foundation ; pas de sections invariantes, pas de textes de couverture et pas de textes de couverture arrière. Une copie de la licence est incluse dans la section intitulée « Licence de documentation gratuite GNU ».

Guide de l'utilisateur de GNU Wget2

Blog sur la Radio et Linux