Ersetzen des Wget-Dienstprogramms durch Wget2 (Teil 2)

Juli

2023

17:41

Ersetzen des Wget-Dienstprogramms durch Wget2 (Teil 2)

Linux

18 Juli 2023 17:41

Zweiter Teil des Artikels.Siehe Teil 1.

HTTP-Optionen:

--default-page=name
Verwenden Sie „name“ als Standarddateinamen, wenn dieser unbekannt ist (z. B. bei URLs, die mit einem Schrägstrich enden), anstelle von „index.html“.

--default-http-port=port
Legen Sie den Standardport für HTTP-URLs fest (Standard: 80).

Wird hauptsächlich zu Testzwecken verwendet.

--default-https-port=port
Legen Sie den Standardport für HTTPS-URLs fest (Standard: 443).

Wird hauptsächlich zu Testzwecken verwendet.

-E, --adjust-extension
Wenn eine Datei wie application/xhtml+xml oder text/html geladen wird und die URL nicht mit dem regulären Ausdruck .[Hh][Tt][Mm][Ll]? endet, führt diese Option dazu, dass das Suffix .html an den lokalen Dateinamen angehängt wird. Dies ist beispielsweise nützlich, wenn Sie eine Remote-Site spiegeln, die ASP-Seiten verwendet, die gespiegelten Seiten aber auf Ihrem Standard-Apache-Server sichtbar sein sollen. Eine weitere gute Verwendung hierfür ist das Laden von CGI-generierten Materialien. Eine URL wie https://example.com/article.cgi?25 wird als Article.cgi?25.html gespeichert.

Beachten Sie, dass auf diese Weise geänderte Dateinamen jedes Mal erneut heruntergeladen werden, wenn Sie die Site erneut spiegeln, da Wget2 nicht erkennen kann, dass die lokale Datei X.html mit der Remote-URL X übereinstimmt (da es noch nicht weiß, dass die URL eine Ausgabe wie text/html oder application/xhtml+xml erzeugt).

Wget2 stellt außerdem sicher, dass alle heruntergeladenen Text-/CSS-Dateien mit dem Suffix .css enden.

Irgendwann in der Zukunft wird diese Option möglicherweise um Suffixe für andere Inhaltstypen erweitert, einschließlich Inhaltstypen, die nicht von Wget analysiert werden.

--http-user=user, --http-password=password
Geben Sie einen Benutzernamen und ein Passwort für die HTTP-Authentifizierung an. Abhängig von der Art der Aufgabe kodiert Wget sie entweder mit dem „Basic“ (unsicher), „Digest“-Windows-Authentifizierungsschema oder „NTLM“.

Wenn möglich, geben Sie Ihre Anmeldeinformationen in ~/.netrc (siehe auch Optionen --netrc und --netrc-file) oder in .wget2rc ein. Dies ist viel sicherer als die Verwendung der Befehlszeile, die für jeden anderen Benutzer sichtbar ist. Wenn Passwörter wirklich wichtig sind, lassen Sie sie nicht in diesen Dateien herumliegen. Bearbeiten Sie die Dateien und löschen Sie sie, nachdem Wget2 mit dem Herunterladen begonnen hat.

In der Datei ~/.netrc können Passwörter in doppelte Anführungszeichen gesetzt werden, um Leerzeichen zu umgehen. Escape-Zeichen können bei Bedarf auch mit einem Backslash versehen werden. Backslashes in Passwörtern sollten immer mit Escapezeichen versehen werden, also verwenden Sie \ anstelle eines einzelnen .

Siehe auch --use-askpass и --ask-password für eine interaktive Methode zur Bereitstellung Ihres Passworts.

--http-proxy-user=user, --http-proxy-password=password
Gibt den Benutzernamen und das Passwort für die Authentifizierung auf dem HTTP-Proxyserver an. Weitere Informationen finden Sie unter --http-user.

--http-proxy=proxies
Gibt eine durch Kommas getrennte Liste von HTTP-Proxys an. Umgebungsvariable http_proxy' будет переопределена. Исключения можно установить с помощью переменной окружения no_proxy' или с помощью --no-proxy.

--https-proxy=proxies
Gibt eine durch Kommas getrennte Liste von HTTPS-Proxys an. Umgebungsvariable https_proxy будет переопределена. Исключения можно установить с помощью переменной окружения no_proxy или с помощью --no-proxy.

--no-http-keep-alive
Deaktivieren Sie Keep-Alive für HTTP(S)-Downloads. Normalerweise fordert Wget2 den Server auf, die Verbindung offen zu halten, sodass beim Herunterladen mehrerer Dokumente vom selben Server diese über dieselbe TCP-Verbindung übertragen werden. Das spart Zeit und reduziert gleichzeitig die Belastung des Servers.

Diese Option ist nützlich, wenn Keep-Alive-Verbindungen aus irgendeinem Grund bei Ihnen nicht funktionieren, beispielsweise aufgrund eines Serverfehlers oder weil Serverskripte nicht in der Lage sind, mit Verbindungen umzugehen.

--no-cache
Deaktiviert den serverseitigen Cache. In diesem Fall sendet Wget2 die entsprechenden Anweisungen (Cache-Control: no-cache und Pragma: no-cache) an den Remote-Server, um die Datei vom Remote-Dienst abzurufen, anstatt die zwischengespeicherte Version zurückzugeben. Dies ist besonders nützlich, um veraltete Dokumente auf Proxyservern abzurufen und zu bereinigen.
Caching ist standardmäßig aktiviert.

--no-cookies
Deaktivieren Sie die Verwendung von Cookies. Cookies sind ein serverseitiger Mechanismus zur Statuserhaltung. Der Server sendet mithilfe des Headers „Set-Cookie“ ein Cookie an den Client, und der Client antwortet mit demselben Cookie auf weitere Anfragen. Da Cookies es Serverbesitzern ermöglichen, Besucher zu verfolgen und Websites die Weitergabe dieser Informationen ermöglichen, werden sie von manchen als Verletzung der Privatsphäre angesehen. Standardmäßig werden Cookies verwendet; das Speichern von Cookies ist jedoch deaktiviert.

--load-cookies file
Laden Sie Cookies aus einer Datei vor der ersten HTTP(S)-Anfrage. Bei der Datei handelt es sich um eine Textdatei im Format, das ursprünglich von der Datei cookie.txt von Netscape verwendet wurde.

Normalerweise verwenden Sie diese Option, wenn Sie Websites spiegeln, bei denen Sie angemeldet sein müssen, um auf einige oder alle Inhalte zugreifen zu können. Der Anmeldevorgang funktioniert normalerweise so, dass der Webserver nach Erhalt und Validierung Ihrer Anmeldeinformationen ein HTTP-Cookie ausgibt. Das Cookie wird dann vom Browser erneut gesendet, wenn Sie auf diesen Teil der Website zugreifen, und bestätigt so Ihre Identität.

Für die Spiegelung einer solchen Website muss Wget2 dieselben Cookies senden, die Ihr Browser bei der Kommunikation mit der Website sendet. Dies wird erreicht durch --load-cookies: Teilen Sie Wget2 einfach den Speicherort der Datei „cookies.txt“ mit und es werden dieselben Cookies gesendet, die Ihr Browser in derselben Situation senden würde. Verschiedene Browser speichern Textcookies an unterschiedlichen Orten:

„Netscape 4.x“. Cookies befinden sich in ~/.netscape/cookies.txt.
„Mozilla und Netscape 6.x“. Das Mozilla-Cookie heißt auch Cookies.txt und befindet sich irgendwo im Ordner ~/.mozilla in Ihrem Profilverzeichnis. Der vollständige Pfad sieht normalerweise etwa so aus: ~/.mozilla/default/some-weird-string/cookies.txt.
„Internet Explorer“. Sie können ein Cookie erstellen, das Wget2 verwenden kann, indem Sie das Menü „Datei“, „Importieren und Exportieren“, „Cookies exportieren“ verwenden. Dies wurde mit Internet Explorer 5 getestet; Es kann nicht garantiert werden, dass es mit früheren Versionen funktioniert.
„Andere Browser“. Wenn Sie zum Erstellen von Cookies einen anderen Browser verwenden,--load-cookies funktioniert nur, wenn Sie ein Cookie im Netscape-Format finden oder erstellen können, das Wget2 erwartet.

Wenn Sie es nicht verwenden können --load-cookies, vielleicht gibt es eine Alternative. Wenn Ihr Browser einen „Cookie-Manager“ unterstützt, können Sie damit die verwendeten Cookies beim Zugriff auf die gespiegelte Seite einsehen. Notieren Sie sich den Cookie-Namen und -Wert und weisen Sie Wget2 manuell an, diese Cookies zu senden und dabei die „offizielle“ Cookie-Unterstützung zu umgehen:
wget2 --no-cookies --header "Cookie: <name>=<value>"

--save-cookies file
Speichern Sie Cookies vor dem Beenden in einer Datei. Dabei werden keine abgelaufenen oder nicht abgelaufenen Cookies (sog. „Session-Cookies“) gespeichert, siehe aber auch die Option --keep-session-cookies.

--keep-session-cookies
Wenn sie angegeben wird, bewirkt die Option --save-cookies speichern auch _Sitzungscookies. Sitzungscookies werden normalerweise nicht gespeichert, da sie so konzipiert sind, dass sie im Speicher gespeichert werden und beim Verlassen des Browsers vergessen werden. Das Speichern ist auf Websites nützlich, bei denen Sie sich anmelden oder die Startseite besuchen müssen, bevor Sie auf einige Seiten zugreifen können. Mit dieser Option werden mehrere Ausführungen von Wget2 aus Sicht der Site als eine Browsersitzung betrachtet.

Da das Cookie-Format normalerweise keine Sitzungscookies enthält, markiert Wget2 sie mit einem Ablaufzeitstempel von 0.
Wget2 --load-cookies распознает их как файлы cookie сеанса, но это может сбить с толку другие браузеры. Также обратите внимание, что файлы cookie, загруженные таким образом, будут рассматриваться как другие файлы cookie сеанса, а это означает, что если вы хотите, чтобы --save-cookies снова их сохраняла, вы должны снова использовать --keep-session-cookies.

--cookie-suffixes=file
Laden Sie öffentliche Suffixe, die für die Cookie-Validierung verwendet werden, aus der angegebenen Datei.

Typischerweise lädt die libpsl-Kernbibliothek diese Daten aus einer Systemdatei oder hat die Daten integriert. In einigen Fällen kann es erforderlich sein, eine aktualisierte öffentliche PSL-Suffixdatei herunterzuladen, beispielsweise von public_suffix_list.dat

Mit PSL können Sie die Installation von „Super-Cookies“ verhindern, die zu Datenschutzlecks bei Cookies führen. Weitere Informationen finden Sie unter https://publicsuffix.org/.

--ignore-length
Leider senden einige HTTP-Server (genauer gesagt CGI-Programme) falsche „Content-Length“-Header, was dazu führt, dass Wget2 verrückt spielt, weil es denkt, dass nicht das gesamte Dokument empfangen wurde. Sie bemerken dieses Syndrom möglicherweise, wenn Wget immer wieder versucht, dasselbe Dokument abzurufen, und dabei jedes Mal behauptet, dass die (ansonsten normale) Verbindung auf demselben Byte geschlossen wurde.

Mit dieser Option ignoriert Wget2 den Header „Content-Length“, als ob er nie existiert hätte.

--header=header-line
Senden Sie die Headerzeile zusammen mit den anderen Headern in jeder HTTP-Anfrage. Der bereitgestellte Header wird unverändert gesendet, d. h. er muss den Namen und den Wert durch einen Doppelpunkt getrennt enthalten und darf keine Zeilenumbrüche enthalten.

Sie können mehr als einen zusätzlichen Header definieren, indem Sie –header mehr als einmal angeben.
wget2 --header='Accept-Charset: iso-8859-2' \ --header='Accept-Language: hr' \ https://example.com/

Durch die Angabe einer leeren Zeichenfolge als Headerwert werden die vorherigen benutzerdefinierten Header gelöscht.

Mit dieser Option können Header überschrieben werden, die ansonsten automatisch generiert werden. In diesem Beispiel wird Wget2 angewiesen, eine Verbindung zu localhost herzustellen, aber example.com im Header „Host“ anzugeben:

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

--max-redirect=number
Geben Sie die maximale Anzahl von Weiterleitungen für die Ressource an. Der Standardwert ist 20, was normalerweise viel höher ist als nötig. Wenn Sie jedoch mehr (oder weniger) zulassen möchten, können Sie diese Option nutzen.

--proxy-user=user, --proxy-password=password(Nicht implementiert, verwenden Sie --http-proxy-password).
Geben Sie den Anmeldebenutzer und das Kennwort für die Authentifizierung am Proxyserver an. Wget2 kodiert sie mithilfe eines „einfachen“ Authentifizierungsschemas.
Sicherheitsüberlegungen wie die betreffenden --http-password, gelten auch hier.

--referer=url
Fügt den Header „Referer: URL“ in die HTTP-Anfrage ein. Nützlich zum Abrufen von Dokumenten mit serverseitiger Verarbeitung, vorausgesetzt, sie werden immer von interaktiven Webbrowsern abgerufen und nur dann ordnungsgemäß gerendert, wenn der Referrer auf eine der Seiten eingestellt ist, die auf sie verweisen.

--save-headers
Speichern Sie die vom HTTP-Server vor dem eigentlichen Inhalt gesendeten Header in einer Datei mit einer Leerzeile als Trennzeichen.

-U agent-string, --user-agent=agent-string
Identifizieren Sie sich auf dem HTTP-Server mit der folgenden Zeile „User-Agent“.

Das HTTP-Protokoll ermöglicht es Clients, sich mithilfe eines „User-Agent“-Headerfelds zu identifizieren. Dies ermöglicht die Differenzierung von WWW-Software, meist zu statistischen Zwecken oder zur Verfolgung von Protokollverstößen. Wget wird normalerweise als Wget/Version identifiziert, wobei Version die aktuelle Versionsnummer von Wget ist.

Es ist jedoch bekannt, dass einige Websites eine Richtlinie zur Anpassung der Ausgabe entsprechend den vom „User-Agent“ bereitgestellten Informationen vorschreiben. Obwohl dies theoretisch keine so schlechte Idee ist, wurde sie von Servern missbraucht, indem sie anderen Clients als (in der Vergangenheit) Netscape oder, häufiger, Microsoft Internet Explorer, Informationen verweigerten. Mit dieser Option können Sie die von Wget zurückgegebene Zeichenfolge „User-Agent“ ändern. Die Verwendung dieser Option wird nicht empfohlen, es sei denn, Sie wissen wirklich, was Sie tun.

--post-data=string, --post-file=file
Verwenden Sie POST als Methode für alle HTTP-Anfragen und senden Sie die angegebenen Daten im Anfragetext.--post-data отправляет строку в виде данных, тогда как --post-file sendet den Inhalt der Datei. Ansonsten funktionieren sie genauso.

Konkret erwarten beide Parameter Inhalte in der Form „key1=value1&key2=value2“ mit prozentualer Kodierung für Sonderzeichen.
Der einzige Unterschied besteht darin, dass der eine seinen Inhalt als Befehlszeilenparameter erwartet, während der andere seinen Inhalt aus einer Datei akzeptiert. Insbesondere ist --post-file nicht dazu gedacht, Dateien als Formularanhänge zu übergeben: Sie sollten wie alles andere als Schlüssel=Wert-Daten (mit entsprechender prozentualer Kodierung) erscheinen.

Derzeit unterstützt Wget2 „multipart/form-data“ für die POST-Datenübertragung nicht. nur „application/x-www-form-urlencoded“. Es muss nur einer der Parameter angegeben werden:--post-data или --post-file.

Beachten Sie, dass wget2 nicht erfordert, dass der Inhalt „key1=value1&key2=value2“ ist, und keine Prüfung darauf durchführt. Wget2 übergibt einfach alle Daten, die ihm bereitgestellt werden. Allerdings erwarten die meisten Server bei der Verarbeitung von HTML-Formularen, dass POST-Daten im oben genannten Format vorliegen.

Beim Senden einer POST-Anfrage mit dem Parameter --post-file wget2 behandelt die Datei als Binärdatei und sendet jedes Zeichen in der POST-Anfrage, ohne nachgestellte Zeilenumbrüche oder Seitenfeeds zu entfernen. Alle anderen Steuerzeichen im Text werden ebenfalls wie in der POST-Anfrage gesendet.

ИмеBeachten Sie, dass Wget2 die Größe der POST-Daten im Voraus kennen muss. Deshalb das Argument --post-file muss eine reguläre Datei sein; Die Angabe von FIFO oder etwas wie /dev/stdin funktioniert nicht. Es ist nicht ganz klar, wie diese mit HTTP/1.0 verbundene Einschränkung umgangen werden kann. Obwohl HTTP/1.1 schrittweise Übertragungen eingeführt hat, die keine vorherige Kenntnis der Anforderungslänge erfordern, kann ein Client diese Übertragung nur verwenden, wenn er weiß, dass er mit einem HTTP/1.1-Server kommuniziert. Und das kann er erst wissen, wenn er eine Antwort erhält, die wiederum die Erfüllung der Bitte erfordert – das „Henne-Ei-Problem“.

Wenn Wget2 nach Abschluss der POST-Anfrage umleitet, hängt sein Verhalten vom vom Server zurückgegebenen Antwortcode ab. Bei „301 dauerhaft verschoben“, „302 vorübergehend verschoben“ oder „307 vorübergehend umgeleitet“ sendet Wget2 weiterhin die POST-Anfrage gemäß RFC2616. Wenn der Server möchte, dass der Client bei der Umleitung die Anforderungsmethode ändert, muss er einen Antwortcode „303 See Other“ senden.

Dieses Beispiel zeigt, wie Sie sich per POST beim Server anmelden und dann mit dem Laden der gewünschten Seiten fortfahren, die vermutlich nur autorisierten Benutzern zugänglich sind:
#Melden Sie sich beim Server an. Dies ist nur einmal möglich. wget2 --save-cookies Cookies.txt \ --post-data 'user=foo&password=bar' \ http://example.com/auth.php #Jetzt erfassen wir die Seite oder Seiten, die für uns interessant sind. wget2 --load-cookies Cookies.txt \ -p http://example.com/interesting/article.php
Wenn der Server Sitzungscookies verwendet, um die Benutzerauthentifizierung zu verfolgen, funktioniert das oben Genannte nicht, weil --save-cookies не сохранит их (как и браузеры), а файл cookies.txt будет пустым. В этом случае используйте ---keep-session-cookies вместе с опцией --save-cookies um das Speichern von Session-Cookies zu erzwingen.

--method=HTTP-Method
Für RESTful-Szenarien können Sie mit Wget2 andere HTTP-Methoden senden, ohne diese explizit festlegen zu müssen --header=Header-Line. Wget2 будет использовать любую строку, переданную ему после --method, als HTTP-Methode für den Server.

--body-data=Data-String, --body-file=Data-File
Diese Option muss festgelegt werden, wenn zusätzlich zu der mit der Option angegebenen Methode zusätzliche Daten an den Server gesendet werden müssen --method. Ключ --body-data отправляет строку как данные, а --body-file sendet den Inhalt der Datei. Ansonsten funktionieren sie genauso.

Derzeit 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.

Wenn Wget2 nach Abschluss der Anfrage umleitet, pausiert Wget2 die aktuelle Methode und sendet eine GET-Anfrage, bis die Umleitung abgeschlossen ist. Dies gilt für alle Redirect-Antwortcodes mit Ausnahme von 307 Temporary Redirect, der verwendet wird, um explizit anzugeben, dass die Anforderungsmethode nicht geändert werden sollte. Eine weitere Ausnahme besteht, wenn die Methode auf „POST“ gesetzt ist. In diesem Fall werden die im Parameter angegebenen Umleitungsregeln befolgt --post-data.

--content-disposition
Wenn diese Option aktiviert ist, ist die experimentelle (nicht voll funktionsfähige) Unterstützung für „Content-Disposition“-Header aktiviert. Dies kann derzeit zu zusätzlichen Zugriffen auf den Server für die „HEAD“-Anfrage führen und weist bekanntermaßen mehrere Fehler auf, sodass es derzeit nicht standardmäßig aktiviert ist.

Diese Option ist für einige CGI-Programme nützlich, die Dateien laden, die „Content-Disposition“-Header verwenden, um zu beschreiben, wie der Name der geladenen Datei lauten soll.

--content-on-error
Wenn diese Option aktiviert ist, übergibt wget2 keinen Inhalt, wenn der Server mit einem HTTP-Statuscode antwortet, der auf einen Fehler hinweist.

--save-content-on
Nach dem Gleichheitszeichen müssen Sie eine durch Kommas getrennte Liste von HTTP-Statuscodes angeben, unter denen der Inhalt gespeichert wird.

Sie können „*“ für ANY verwenden. Ein Ausrufezeichen (!) vor dem Code bedeutet „Ausnahme“.

Beispiel 1:--save-content-on="*,!404" speichert Inhalte mit anderen HTTP-Statuscodes als 404.

Beispiel 2:--save-content-on=404 speichert nur Inhalte mit dem HTTP-Statuscode 404.

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

--trust-server-names
Wenn diese Einstellung aktiviert ist, wird bei der Umleitung die letzte Komponente der Umleitungs-URL als lokaler Dateiname verwendet. Standardmäßig wird die letzte Komponente der Quell-URL verwendet.

--auth-no-challenge
Wenn dieser Parameter angegeben ist, sendet Wget2 für alle Anfragen grundlegende HTTP-Authentifizierungsinformationen (unverschlüsselter Benutzername und Passwort).

Die Verwendung dieser Option wird nicht empfohlen und ist nur dazu gedacht, einige obskure Server zu unterstützen, die niemals HTTP-Authentifizierungsanfragen senden, aber beispielsweise zusätzlich zur formularbasierten Authentifizierung unerwünschte Authentifizierungsinformationen akzeptieren.

--compression=TYPE
Wenn dieser Komprimierungstyp angegeben ist (identity, gzip, deflate, xz, lzma, br, bzip2, zstd, lzip oder eine beliebige Kombination davon), legt Wget2 den Header „Accept-Encoding“ entsprechend fest. --no-compression bedeutet überhaupt keinen „Accept-Encoding“-Header. Um einen benutzerdefinierten „Accept-Encoding“-Wert festzulegen, verwenden Sie --no-compression в сочетании с --header="Accept-Encoding: xxx".

Kompatibilitätshinweis: Wget 1.X bietet nicht die Möglichkeit, den Komprimierungstyp anzugeben, wie Wget2.

--download-attr=[strippath|usepath]
Das HTML5-Download-Attribut kann den Dateinamen aus der href-URL in den Tags „a“ und „area“ angeben (oder besser: vorschlagen). Diese Option weist Wget2 an, diesen Namen beim Speichern der Datei zu verwenden. Zwei mögliche Werte: „strippath“, um den Pfad aus dem Dateinamen zu entfernen. Dies ist der Standardwert.

Bedeutung usepath akzeptiert einen Dateinamen inklusive Verzeichnis. Es ist sehr gefährlich und wir können es nicht bedenkenlos auf nicht vertrauenswürdigen Eingaben oder Servern verwenden! Verwenden Sie dies nur, wenn Sie der Eingabe oder dem Server wirklich vertrauen.

HTTPS-Optionen (SSL/TLS).

Um HTTP (HTTPS)-verschlüsselte Downloads zu unterstützen, muss Wget2 mit externer SSL-Bibliotheksunterstützung kompiliert werden. Derzeit wird standardmäßig GnuTLS verwendet. Darüber hinaus unterstützt Wget2 auch HSTS (HTTP Strict Transport Security). Wenn Wget2 ohne SSL-Unterstützung kompiliert wird, ist keine dieser Optionen verfügbar.

--secure-protocol=protocol
Wählen Sie das zu verwendende sichere Protokoll aus (Standard: automatisch).

Zulässige Werte auto, SSLv3, TLSv1, TLSv1_1, TLSv1_2, TLSv1_3 и PFS.

Falls verwendet auto, wird der standardmäßige TLS-Bibliotheksmodus angewendet.

УкаWenn Sie SSLV3 kennen, müssen Sie SSL3 verwenden. Dies ist nützlich, wenn Sie mit älteren und fehlerhaften SSL-Serverimplementierungen arbeiten, bei denen es schwierig ist, die TLS-Protokollversion mithilfe der zugrunde liegenden TLS-Bibliothek korrekt auszuwählen.

Durch die Angabe von PFS wird die Einhaltung der sogenannten Perfect Forward Security Sets sichergestellt. Kurz gesagt bietet PFS die Sicherheit, für jede TLS-Verbindung einen einmaligen Schlüssel zu generieren. Dadurch wird die Client- und Server-CPU etwas stärker belastet. Uns bekannt als sichere Chiffren (z. B. ohne MD4) und das TLS-Protokoll.

TLSV1 aktiviert TLS1.0 oder höher. TLSV1_1 aktiviert TLS1.1 oder höher. TLSV1_2 aktiviert TLS1.2 oder höher. TLSV1_3 aktiviert TLS1.3 oder höher.

Jede andere Protokollzeichenfolge wird als „Präzedenz“- oder „Chiffre“-Zeichenfolge direkt an die TLS-Bibliothek, derzeit Gnutls, übergeben.
Diese Option ist für Benutzer gedacht, die verstehen, was sie tun.

--https-only
Im Rekursionsmodus folgt das Programm nur HTTPS-Links.

--no-check-certificate
Vergleichen Sie das Serverzertifikat nicht mit verfügbaren Zertifizierungsstellen. Kann auch verwendet werden, wenn der Host-URL-Name nicht mit dem vom Zertifikat dargestellten allgemeinen Namen übereinstimmt.

Standardmäßig wird die Überprüfung des Serverzertifikats gegenüber Zertifizierungsstellen durchgeführt, wobei der SSL-Handshake unterbrochen und der Startvorgang abgebrochen wird, wenn die Zertifikatsüberprüfung fehlschlägt. Dies sorgt zwar für sicherere Downloads, beeinträchtigt jedoch die Kompatibilität mit einigen Websites, die mit früheren Versionen von WGET funktionierten, insbesondere solchen, die selbstsignierte, abgelaufene oder anderweitig ungültige Zertifikate verwenden. Diese Option erzwingt einen „unsicheren“ Betriebsmodus, der Fehler bei der Zertifikatsüberprüfung in Warnungen umwandelt und es Ihnen ermöglicht, fortzufahren.

Wenn Sie auf Fehler bei der „Zertifikatüberprüfung“ stoßen oder erwähnen, dass „der allgemeine Name nicht mit dem angeforderten Hostnamen übereinstimmt“, können Sie diese Option verwenden, um die Überprüfung zu umgehen und den Download fortzusetzen. Verwenden Sie diese Option nur, wenn Sie von der Authentizität der Website überzeugt sind oder wenn Ihnen die Gültigkeit des Zertifikats wirklich egal ist. Es ist fast immer eine schlechte Idee, Zertifikate bei der Übertragung sensibler oder wichtiger Daten nicht zu überprüfen. Für mich

Selbstsignierte/interne Zertifikate: Sie sollten das Zertifikat herunterladen und es vergleichen, anstatt diesen unsicheren Modus zu erzwingen. Wenn Sie wirklich sicher sind, dass Sie keine Zertifikatsüberprüfung wünschen, können Sie dies angeben --check-certificate=quiet um WGET2 anzuweisen, keine Warnungen über ungültige Zertifikate auszugeben, obwohl dies in den meisten Fällen falsch ist.

--certificate=file
Verwenden Sie das in der Datei gespeicherte Client-Zertifikat. Diese Option ist für Server erforderlich, die so konfiguriert sind, dass sie Zertifikate von Clients erfordern, die eine Verbindung zu ihnen herstellen. Normalerweise ist kein Zertifikat erforderlich und dieser Schalter ist optional.

--certificate-type=type
Gibt den Typ des Client-Zertifikats an. Die wahrgenommenen Werte sind PEM (Standard) oder DER, auch bekannt als ASN1.

--private-key=file
Lesen Sie einen privaten Schlüssel aus einer Datei. Mit dieser Option können Sie den privaten Schlüssel in einer vom Zertifikat getrennten Datei bereitstellen.

--private-key-type=type
Geben Sie den Typ des privaten Schlüssels an. Wahrgenommene Werte von PEM (Standard) und DER.

--ca-certificate=file
Verwenden Sie eine Datei, die eine Reihe von Zertifizierungsstellenzertifikaten („CA“) speichert, um die Parteien zu überprüfen. Zertifikate müssen im PEM-Format vorliegen.

Ohne Angabe dieser Option sucht Wget2 nach CA-Zertifikaten in den Systemspeicherorten (Ordnern), die während der OpenSSL-Installation ausgewählt wurden.

--ca-directory=directory
Gibt das Verzeichnis an, das Zertifikate der Zertifizierungsstelle (CA) im PEM-Format enthält. Jede Datei enthält ein Zertifikat einer Zertifizierungsstelle (CA), und der Dateiname wird vom Hashwert dieser Zertifikatsdatei abgeleitet. Dies wird durch die Verarbeitung des Zertifikatverzeichnisses mit dem mit OpenSSL bereitgestellten Dienstprogramm „C_REHASH“ erreicht. Die Verwendung von --ca-directory ist effizienter als --ca-certificate, wenn viele Zertifikate installiert sind, da WGET2 so Zertifikate bei Bedarf abrufen kann.

Ohne diese Option sucht WGET2 an den während der OpenSSL-Installation ausgewählten Systemstandorten nach CA-Zertifikaten.

--crl-file=file
Gibt die Zertifikatssperrdatei (CRL) an. Es ist erforderlich, Zertifikate anzugeben, die von Zertifizierungsstellen (CAs) widerrufen wurden.

--random-file=file
(Nur für OpenSSL und LibreSSL). Verwenden Sie die Datei als Quelle für Zufallsdaten für Pseudozufallszahlengenerator-Seeds auf einem System ohne das Gerät /dev/urandom.

Auf solchen Systemen benötigt die SSL-Bibliothek zur Initialisierung eine externe Zufallsquelle. Die Zufälligkeit kann vom EGD bereitgestellt werden (siehe –EGD unten) oder aus einer vom Benutzer angegebenen externen Quelle gelesen werden. Wenn diese Option nicht angegeben ist, sucht WGET2 nach Zufallsdaten in $randfile oder, falls dies falsch ist, in $home/.rnd.

Wenn Sie die Fehlermeldung „OpenSSL PRNG konnte nicht gesetzt werden; SSL wird deaktiviert.“_ erhalten, sollten Sie mithilfe einiger der oben beschriebenen Methoden Zufallsdaten bereitstellen.

--egd-file=file
[Nur OpenSSL] Verwenden Sie die Datei als EGD-Socket. Das Akronym EGD steht für Entropy Gathering Daemon, ein User-Space-Programm, das Daten aus verschiedenen unvorhersehbaren Systemquellen sammelt und es anderen Programmen, die Verschlüsselung verwenden, ermöglicht, Entropie zu nutzen, wie zum Beispiel der SSL-Bibliothek, die Quellen mit sich nicht wiederholenden Zufallswerten benötigt, um den Zufallszahlengenerator zu starten, der zum Erstellen kryptografisch starker Schlüssel verwendet wird.

OpenSSL ermöglicht es dem Benutzer, mithilfe der Umgebungsvariablen „RAND_FILE“ seine eigene Entropiequelle anzugeben. Wenn diese Variable nicht gesetzt ist oder die angegebene Datei keine ausreichende Zufälligkeit bietet, liest OpenSSL zufällige Daten aus dem mit dieser Option angegebenen EGD-Socket.

Wenn diese Option nicht angegeben ist (und der entsprechende Ausführungsbefehl nicht verwendet wird), wird EGD nie zugeordnet. EGD ist auf modernen UNIX-Systemen, die /dev/urandom unterstützen, nicht erforderlich.

--hsts
WGET2 unterstützt standardmäßig HSTS (HTTP Strict Transport Security, RFC 6797). Verwenden Sie --no-hsts, um WGET2 zu zwingen, als nicht HSTS-kompatibler Benutzeragent zu fungieren. Infolgedessen ignoriert WGET2 alle „Strict-Transport-Security“-Header und erzwingt keine bestehende HSTS-Richtlinie.

--hsts-file=file
Standardmäßig speichert WGET2 seine HSTS-Daten in $xdg_data_home/wget/.wget-hsts oder, wenn xdg_data_home nicht festgelegt ist, in ~/.lo-cal/wget/.wget-hsts. Sie können dies mit --hsts-file überschreiben.

WGET2 verwendet die bereitgestellte Datei als HSTS-Datenbank. Eine solche Datei muss dem richtigen HSTS-Datenbankformat entsprechen, das von WGET verwendet wird. Wenn WGET2 die bereitgestellte Datei nicht analysieren kann, ist das Verhalten undefiniert.

Um den dauerhaften Speicher zu deaktivieren, verwenden Sie --no-hsts-file.

Die Wget2 HSTS-Datenbank ist eine einfache Textdatei. Jede Zeile enthält einen HSTS-Eintrag (d. h. die Site, die den Header „Strict-Transport-Security“ ausgegeben und daher die spezifische anzuwendende HSTS-Richtlinie angegeben hat). Zeilen, die mit einem Bindestrich beginnen ("#"), werden von Wget ignoriert. Bitte beachten Sie, dass trotz dieser für Menschen lesbaren Form ein manuelles Patchen der HSTS-Datenbank im Allgemeinen keine gute Idee ist.

Die HSTS-Eingabezeile besteht aus mehreren Feldern, die durch ein oder mehrere Leerzeichen getrennt sind:

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

ПолDer Hostname und der Port geben den Hostnamen und Port an, für den diese HSTS-Richtlinie gilt. Das Feld „Port“ kann leer sein und wird in den meisten Fällen auch leer sein. Dies bedeutet, dass die Portnummer bei der Entscheidung, ob diese HSTS-Richtlinie auf eine bestimmte Anfrage angewendet werden soll, nicht berücksichtigt wird (nur der Hostname wird ausgewertet). Wenn der Port nicht leer ist, werden sowohl der Ziel-Hostname als auch der Port ausgewertet und die HSTS-Richtlinie wird nur angewendet, wenn sowohl der Host-Port als auch der Port in der Datei übereinstimmen. Diese Funktion wurde nur zu Test-/Entwicklungszwecken aktiviert. TestSuite WGET2 (in TestenV/) erstellt HSTS-Datenbanken mit expliziten Ports, um das korrekte Wget2-Verhalten sicherzustellen. Anwenden von HSTS-Richtlinien auf nicht standardmäßige Ports, RFC 6797 (siehe Anhang B, „Unterschiede zwischen ‚HSTS-Richtlinie und Same-Origin-Richtlinie‘“). Daher sollte diese Funktionalität nicht in Produktionsumgebungen verwendet werden und der Port ist normalerweise leer.

Die letzten drei Felder tun, was von ihnen erwartet wird. Das Feld „include_subdomains“ kann entweder 1 oder 0 sein und signalisiert, ob Subdomains der Zieldomäne ebenfalls Teil dieser HSTS-Richtlinie sein sollen. Die Felder „created“ und „max_age“ enthalten den Zeitstempel, als der Datensatz erstellt wurde (erstmals von WGET gesehen) und den HSTS-definierten Wert max-age, der angibt, wie lange diese HSTS-Richtlinie aktiv bleibt, gemessen in Sekunden seit der letzten Erstellung des Zeitstempels, der im Feld „erstellt“ gespeichert wird. Nach Ablauf dieser Zeit ist diese HSTS-Richtlinie nicht mehr gültig und wird schließlich aus der Datenbank gelöscht.

Wenn Sie über die Option Ihre eigene HSTS-Datenbank bereitstellen --hsts-file beachten Sie, dass WGET2 die bereitgestellte Datei ändern kann, wenn eine Änderung zwischen den von den Remote-Servern angeforderten HSTS-Richtlinien und den Richtlinien in der Datei auftritt. Wenn Wget2 beendet wird, aktualisiert es effektiv die HSTS-Datenbank, indem es die Datenbankdatei mit neuen Einträgen neu schreibt.

Wenn die bereitgestellte Datei nicht vorhanden ist, wird sie von WGET2 erstellt. Diese Datei enthält die neuen HSTS-Datensätze. Wenn keine HSTS-Einträge generiert wurden (kein „Strict-Transport-Security“-Header von einem der Server gesendet wurde), wird die Datei nicht erstellt, auch wenn sie leer ist. Dieses Verhalten gilt für die Standarddatenbankdatei (~/.wget-HSTS): Sie wird erst erstellt, wenn ein Server die Anwendung der HSTS-Richtlinie veranlasst.

Achten Sie darauf, mögliche Änderungen, die von anderen WGET2-Prozessen gleichzeitig an der HSTS-Datenbank vorgenommen werden, nicht zu überschreiben. Bevor aktualisierte HSTS-Einträge in einer Datei geleert werden, liest WGET2 diese erneut und führt die Änderungen zusammen.

Verwenden einer benutzerdefinierten HSTS-Datenbank und/oder Ändern einer vorhandenen Datenbank. Weitere Informationen zu den potenziellen Sicherheitsrisiken, die sich aus dieser Vorgehensweise ergeben, finden Sie in Abschnitt 14 „Sicherheitsüberlegungen“ von RFC 6797, insbesondere Abschnitt 14.9 „Kreative Manipulation des HSTS-Richtliniensatzes“.

--hsts-preload
Ermöglicht das Laden der HSTS-Preload-Liste entsprechend der libhsts-Unterstützung. (Standard: aktiviert, wenn mit Libhsts erstellt).

--hsts-preload-file=file
Wenn Wget2 mit libhsts-Unterstützung erstellt wird, verwendet WGET2 die vom Installationsprogramm bereitgestellten HSTS-Daten. Wenn diese nicht in der Distribution enthalten ist oder Sie Ihre eigene Datei hochladen möchten, nutzen Sie diese Option.

Die Daten in dieser Datei müssen im DAFSA-Format vorliegen, wie es vom libhsts-Programm des hsts-make-dafsa-Pakets generiert wird.

--hpkp
Aktivieren Sie HTTP Public Key Pinning (HPKP) (Standard: aktiviert).

Dieser Trust On First Use (TOFU)-Mechanismus fügt HTTPS eine weitere Sicherheitsebene hinzu (siehe RFC 7469).

Die Zertifikatsschlüsseldaten der zuvor aufgebauten TLS-Sitzung werden mit den aktuellen Daten verglichen. Falls beide nicht übereinstimmen, wird die Verbindung abgebrochen.

--hpkp-file=file
Standardmäßig speichert WGET2 seine HPKP-Daten in $ xdg_data_home/wget/.wget-hpkp oder, wenn xdg_data_home nicht festgelegt ist, in ~/.lo-cal/wget/.wget-hpkp. Sie können dieses Verhalten mit --hpkp-file außer Kraft setzen.

WGET2 verwendet die angegebene Datei als HPKP-Datenbank. Eine solche Datei muss dem korrekten verwendeten HPKP-Datenbankformat entsprechen
Wget. Wenn WGET2 die bereitgestellte Datei nicht analysieren kann, ist das Verhalten undefiniert.

Um den Speicher zu deaktivieren, verwenden Sie --no-hpkp-file.

--tls-resume
Aktivieren Sie die Wiederaufnahme der TLS-Sitzung, die standardmäßig deaktiviert ist.

Um eine TLS-Sitzung fortzusetzen, sind Daten aus einer zuvor eingerichteten TLS-Sitzung erforderlich.

Mit der Wiederaufnahme der TLS 1.2-Sitzung sind mehrere Sicherheitslücken verbunden, die ausführlich erläutert werden an der Adresse.

--tls-session-file=file
Standardmäßig speichert Wget2 seine TLS-Sitzungsdaten in $xdg_data_home/wget/.wget-session oder, wenn xdg_data_home nicht festgelegt ist, in
~/.local/wget/.wget-session. Sie können --tls-session-file verwenden, um es zu überschreiben.

WGET2 verwendet die angegebene Datei als TLS-Sitzungsdatenbank. Eine solche Datei muss dem richtigen TLS-Sitzungsdatenbankformat entsprechen, das von WGET verwendet wird. Wenn WGET2 die bereitgestellte Datei nicht analysieren kann, ist das Verhalten undefiniert.

Um den dauerhaften Speicher zu deaktivieren, verwenden Sie --no-tls-session-file.

--tls-false-start
TLS-Falschstart aktivieren (Standard: aktiviert).

Diese Option reduziert die TLS-Verhandlungen um einen Roundtrip und beschleunigt so HTTPS-Verbindungen.

Weitere Informationen unter https://tools.ietf.org/html/rfc7918.

--check-hostname
Aktivieren Sie die TLS-SNI-Überprüfung (Server Name Indication) (Standard: aktiviert).

--ocsp
Aktivieren Sie den OCSP-Zugriff auf den Server, um zu prüfen, ob die HTTPS-Zertifikate des Servers widerrufen werden können (Standard: aktiviert).

Dieser Vorgang ist ziemlich langsam (Verbindung zum Server herstellen, HTTP-Anfrage, Antwort) und daher unterstützen wir OSCP-Stapling (Server sendet OCSP-Antwort im TLS-Handshake) und stellen dauerhaftes OCSP-Caching bereit.

--ocsp-date
Überprüfen Sie, ob die OCSP-Antwort zu alt ist. (Standard: aktiviert)

--ocsp-nonce
Nonce-Prüfung bei der Validierung einer OCSP-Antwort zulassen. (Standard: aktiviert)

--ocsp-server
Geben Sie die OCSP-Serveradresse an (Standard: im Zertifikat angegebener OCSP-Server).

--ocsp-stapling
Aktivieren Sie die OCSP-Heftunterstützung (Standard: aktiviert).

--ocsp-file=file
Standardmäßig speichert WGET2 seine TLS-Sitzungsdaten in $xdg_data_home/wget/.wget-ocsp или, если xdg_data_home не установлен, в ~/.local/wget/.wget-ocsp. Вы можете использовать --ocsp-file um dies außer Kraft zu setzen.

WGET2 verwendet die angegebene Datei als OCSP-Datenbank. Eine solche Datei muss dem richtigen OCSP-Datenbankformat entsprechen, das von WGET verwendet wird. Wenn WGET2 die bereitgestellte Datei nicht analysieren kann, ist das Verhalten undefiniert.

Um das dauerhafte OCSP-Caching zu deaktivieren, verwenden Sie --no-ocsp-file.

--dane(experimentelle Funktion)
Aktivieren Sie die Unterstützung für die DANE-Zertifikatsüberprüfung (Standard: deaktiviert).

Für den Fall, dass die Serverüberprüfung aufgrund fehlender CA-Zertifikate fehlschlägt (z. B. ein leerer Zertifizierungspool), ermöglicht diese Option die Überprüfung von TLSA-DNS-Einträgen über DANE.

Sie sollten DNSSEC installieren, um MITM-Angriffe zu vermeiden. Darüber hinaus müssen die Ziel-DNS-Hosteinträge für DANE konfiguriert werden.

Warnung: Diese Option oder ihr Verhalten können sich ohne weitere Ankündigung ändern oder entfernt werden.

--http2
Aktivieren Sie die HTTP/2-Protokollunterstützung (Standard: aktiviert).

Wget2 fordert HTTP/2 über ALPN an. Falls verfügbar, wird es anstelle von HTTP/1.1 verwendet. Innerhalb einer Verbindung werden bis zu 30 Threads parallel genutzt.

--http2-only

Widerstehen Sie und verwenden Sie nur HTTP/2-Verbindungen und geben Sie einen Fehler aus, wenn der Server dies nicht akzeptiert. Hauptsächlich zum Testen.

--https-enforce=mode
Legt fest, wie mit URLs umgegangen wird, für die kein explizites Schema angegeben ist (solche mit einem anderen Schema als https://) (Standardmodus: keine)

mode=none
Verwenden Sie den HTTP-Modus in URLs ohne Schema. Die rekursive Operation verwendet das Schema des übergeordneten Dokuments.

mode=soft
Versuchen Sie es zuerst mit HTTPS, wenn das HTTP-Schema nicht angegeben ist. Wenn ein Fehler auftritt, kehren Sie zum Backup-HTTP zurück.

mode=hard
Verwenden Sie ausschließlich HTTPS, unabhängig davon, ob das HTTP-Schema angegeben ist oder nicht. Greifen Sie nicht auf Fallback-HTTP zurück.

Plugin-Optionen

--list-plugins
Drucken Sie eine Liste aller verfügbaren Plugins aus und beenden Sie den Vorgang.

--local-plugin=file
Laden Sie die Datei als Plugin hoch.

--plugin=name
Laden Sie ein Plugin mit dem angegebenen Namen aus den in der Konfiguration angegebenen Plugin-Verzeichnissen.

--plugin-dirs=directories
Plugin-Verzeichnisse einrichten. Plugin-Verzeichnisse in der Liste werden durch Kommas getrennt.

--plugin-help
Drucken Sie die Hilfe für alle heruntergeladenen Plugins aus.

--plugin-opt=option
Geben Sie Plugin-spezifische Parameter an

Plugin-Parameter „option“ werden im Format angegeben <plugin_name>.<option>[=value].

Umgebung: Proxyserver

Wget2 unterstützt Abruf-Proxys über beide Protokolle, HTTP und HTTPS. Die Standardmethode zum Angeben eines Proxy-Standorts, den WGET erkennt, ist die Verwendung der folgenden Umgebungsvariablen:

http_proxy
https_proxy

Falls angegeben, müssen die Variablen http_proxy und https_proxy die Proxy-URLs für HTTP- bzw. HTTPS-Verbindungen enthalten.

no_proxy

Diese Variable sollte eine durch Kommas getrennte Liste von Domänen enthalten, für die keine Proxys verwendet werden sollen. Wenn der Wert von no_proxy beispielsweise .example.com ist, wird der Proxy nicht zum Abrufen von Dokumenten von *.example.com verwendet.

Abschlusscodes

WGET2 kann einen von mehreren Fehlercodes zurückgeben, wenn Probleme auftreten.

0 gab es keine Probleme.
1 allgemeiner Fehlercode.
2 Parsing-Fehler. Beispielsweise ein Fehler beim Parsen von Befehlszeilenparametern oder .wget2rc- oder .netrc-Dateien ...
3 Datei-Eingabe-/Ausgabefehler.
4 Netzwerkfehler.
5 SSL-Überprüfung fehlgeschlagen.
6 Authentifizierung mit Benutzername/Passwort fehlgeschlagen.
7 Protokollfehler.
8 Der Server antwortete mit einem Fehlercode.
9 Der öffentliche Schlüssel fehlt im Schlüsselring.
10 Signaturüberprüfung fehlgeschlagen.

Mit Ausnahme von 0 und 1 haben Exit-Codes mit niedriger Nummer Vorrang vor Exit-Codes mit höherer Nummer, wenn mehrere Fehlertypen auftreten.

Datei starten

Вы Möglicherweise möchten Sie das Standardverhalten von GNU WGET2 dauerhaft ändern. Es gibt eine bessere Möglichkeit, dies zu tun, als einen Befehlsalias in Ihrer Shell festzulegen. Mit GNU WGET2 können Sie alle Parameter dauerhaft über die Startdatei .WGET2RC festlegen.

Obwohl .WGET2RC die Hauptinitialisierungsdatei ist, die von GNU WGET2 verwendet wird, ist es keine gute Idee, Passwörter in dieser Datei zu speichern.
Dies liegt daran, dass die Startdatei öffentlich lesbar sein oder unter Versionskontrolle archiviert werden kann. Aus diesem Grund liest WGET2 bei Bedarf auch den Inhalt der Datei $Home/.NETRC.

Die .WGET2RC-Datei folgt einer sehr ähnlichen Syntax wie .WGETRC, das von GNU WGET gelesen wird. Es unterscheidet sich nur an den Stellen, an denen die Befehlszeilenoptionen zwischen wget1.x und wget2 variieren.

Standort von Wget2rc

Bei der Initialisierung versucht WGET2, die „globale“ Startdatei zu lesen, die sich standardmäßig unter befindet /usr/local/etc/wget2rc' (или какой -то префикс, отличный от/usr/local‘, wenn Wget2 dort nicht installiert wurde). Die globale Startdatei ist für Systemadministratoren nützlich, um Standardrichtlinien durchzusetzen, z. B. das Festlegen des Zertifikatspeicherpfads, das Vorladen der HSTS-Liste usw.

Wget2 sucht dann nach der Benutzerinitialisierungsdatei. Wenn der Benutzer die Befehlszeilenoption verwendet hat --config wget2 wird versuchen, die Datei herunterzuladen, auf die es verweist. Wenn die Datei nicht vorhanden ist oder nicht gelesen werden kann, unternimmt WGET2 keinen weiteren Versuch, Initialisierungsdateien zu lesen.

Wenn die Umgebungsvariable WGET2RC festgelegt ist, versucht WGET2, die Datei vom angegebenen Pfad herunterzuladen. Wenn die Datei nicht existiert oder nicht gelesen werden kann, unternimmt WGET2 keinen weiteren Versuch, die Initialisierungsdatei zu lesen.

Wenn -config fehlschlägt und WGET2RC nicht installiert ist, versucht WGET2, die Benutzerinitialisierungsdatei von dem Speicherort zu laden, der in der XDG-Basisverzeichnisspezifikation definiert ist. Es liest die erste und nur die erste Datei, die es an den folgenden Speicherorten findet:

1.$XDG_CONFIG_HOME/wget/wget2rc

2.$HOME/.config/wget/wget2rc

3.$HOME/.wget2rc

Der Speicherort der Initialisierungsdatei in $home/.wget2rc ist veraltet. Wenn dort eine Datei gefunden wird, gibt WGET2 eine Warnung darüber aus. Die Unterstützung für das Lesen aus dieser Datei wird in Zukunft entfernt.

Die Tatsache, dass die Benutzereinstellungen nach den globalen geladen werden, bedeutet, dass im Falle eines Konflikts das WGET2RC des Benutzers das globale WGET2RC überschreibt.

Fehler

Sie können Fehlerberichte über den Gnu Wget2 Tracker (https://gitlab.com/gnuwget/wget2/issues) einreichen.

Bevor Sie tatsächlich einen Fehlerbericht einreichen, befolgen Sie einige einfache Richtlinien.

Bitte versuchen Sie herauszufinden, ob es sich bei dem beobachteten Verhalten tatsächlich um einen Fehler handelt. Wenn Wget2 abstürzt, ist das ein Fehler. Wenn sich Wget2 nicht wie dokumentiert verhält, liegt ein Fehler vor. Wenn die Dinge seltsam funktionieren, Sie aber nicht sicher sind, wie sie funktionieren sollen, könnte es durchaus ein Fehler sein, aber Sie sollten die Dokumentation und Mailinglisten noch einmal überprüfen.
Versuchen Sie, den Fehler unter möglichst einfachen Umständen zu reproduzieren. Zum Beispiel. Wenn WGET2 beim Laden von WGET2 -RL0 -KKE -T5 --no-proxy https://example.com -o/tmp/log abstürzt, sollten Sie versuchen zu sehen, ob der Absturz erneut auftritt und mit einem einfacheren Satz von Optionen auftritt. Sie können sogar versuchen, den Ladevorgang auf der Seite zu starten, auf der der Absturz aufgetreten ist, um festzustellen, ob diese Seite den Absturz irgendwie verursacht hat.

Auch wenn ich wahrscheinlich daran interessiert wäre, den Inhalt Ihrer .WGET2RC-Datei zu erfahren, ist es wahrscheinlich eine schlechte Idee, ihn einfach in eine Debug-Nachricht zu kopieren. Stattdessen sollten Sie zunächst versuchen, festzustellen, ob der Fehler erneut auftritt, wenn .WGET2RC aus dem Weg geräumt wird. Nur wenn sich herausstellt, dass die .wget2rc-Einstellungen zum Fehler beitragen, senden Sie mir bitte die relevanten Teile der Datei per E-Mail.

Bitte führen Sie wget2 mit der Option aus -d und senden Sie uns die resultierende Ausgabe (oder relevante Teile davon). Wenn Wget2 ohne Debug-Unterstützung kompiliert wurde, kompilieren Sie es erneut. Es ist viel einfacher, Fehler mithilfe des Debuggens zu verfolgen.

NOTIZ. Entfernen Sie unbedingt alle potenziell vertraulichen Informationen aus dem Debug-Protokoll, bevor Sie sie an die Fehleradresse senden. -D wird sich nicht die Mühe machen, vertrauliche Informationen zu sammeln, aber das Protokoll wird eine ziemlich vollständige Transkription der Kommunikation von Wget2 mit dem Server enthalten, die Passwörter und Teile der heruntergeladenen Daten enthalten kann. Da die Fehleradresse öffentlich ist, können Sie davon ausgehen, dass alle Fehlerberichte für die Öffentlichkeit sichtbar sind.

Wenn Wget2 defekt ist, versuchen Sie, es in einem Debugger wie GDB auszuführen What Wget core und geben Sie „where“ ein, um den Backtrace zu erhalten. Dies funktioniert möglicherweise nicht, wenn der Systemadministrator die Kerndateien deaktiviert hat, aber es ist sicher, es zu versuchen.

Autor

Wget2, geschrieben von Tim Ruehsen tim.ruehsen@gmx.de
Wget 1.x, ursprünglich geschrieben von Hrvoje Nikthić hniksic@xemacs.org

Urheberrecht

Es wird die Erlaubnis erteilt, dieses Dokument gemäß den Bedingungen der GNU-Lizenz, Version 1.3 oder einer späteren Version, veröffentlicht von der Free Software Foundation, zu kopieren, zu verteilen und/oder zu ändern. keine unveränderlichen Abschnitte, keine Texte auf der Vorderseite und keine Texte auf der Rückseite. Eine Kopie der Lizenz ist im Abschnitt „GNU Free Documentation License“ enthalten.

GNU Wget2-Benutzerhandbuch

Blog über Radio und Linux