Wtk: Mit Wget _nur_ die herunterzuladene Größe aller Dateien prüfen

Hallo Leutz!

Ich weiß, wie ich mit Wget auf meinem Webspace ein ganzes Verzeichnis herunterladen kann.
Momentan mache ich das mit:

wget.exe -nc -k -r -np -e http://example.org/meinverzeichnis/

Was ist aber, wenn ich nur wissen will, wie groß die herunterzuladenen Dateien insgesamt wären? Gibt es dafür einen Schalter oder eine sonstige Einstellungsmöglichkeit? Ich würde das dann gerne mit "wget.exe ... >> size.txt" speichern lassen.
Also falls ihr da eine Möglichkeit kennt, sagt sie mir bitte, in der Doku bin ich nicht fündig geworden.

Vielen Dank!

PS: Ich arbeite mit der neuesten Wget Version auf Kommandozeile unter Windows XP.

  1. Du müßtest einen HEAD Request machen - allerdings weiss ich nicht, ob und wie das mit wget geht.

    Gruß, LX

    --
    X-Self-Code: sh:( fo:) ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: Unusual
    X-Please-Search-Archive-First: Absolutely Yes
    1. Moin Moin!

      Du müßtest einen HEAD Request machen - allerdings weiss ich nicht, ob und wie das mit wget geht.

      Ich fürchte, das geht nicht, weder mit wget noch mit irgendeinem anderen Tool: Wie soll wget oder sonst irgendein User-Agent rekursiv Links folgen, wenn er die HTML-Resourcen mit den Links nicht herunterladen darf?

      "ssh user@server du -s -h /srv/www/htdocs" wäre vermutlich eher sinnvoll.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
      1. Moin Moin!

        Du müßtest einen HEAD Request machen - allerdings weiss ich nicht, ob und wie das mit wget geht.

        Ich fürchte, das geht nicht, weder mit wget noch mit irgendeinem anderen Tool: Wie soll wget oder sonst irgendein User-Agent rekursiv Links folgen, wenn er die HTML-Resourcen mit den Links nicht herunterladen darf?

        Ich könnte ja veranlassen, dass das Programm zumindest die "index.html"-Dateien herunterlädt. Das würde schon reichen, anderen Links als in diesen Dateien muss nicht gefolgt werden. Und z.B. php-Dateien oder andere Dateien, sollen halt nicht heruntergeladen werden, sondern es soll nur die Größe erfasst werden. (Der Server sendet die Größe auch mit)

        =/

        1. Moin Moin!

          index.html ist nur eine Konvention, und enthält nicht notwendigerweise alle relevanten Links. Wenn Webserver dynamisch Verzeichnislistings generieren, gibt es in aller Regel überhaupt keine Datei mit Links, sondern das Listing wird ausschließlich im Speicher generiert.

          Andererseits kann eine *.php-Datei oder auch ein CGI-Script von wenigen Bytes Resourcen im Gigabyte-Bereich ausliefern.

          Dazu kann noch ein und die selbe Datei unter unterschiedlichen URLs ausgeliefert werden, z.B. durch Rewrite Rules, interne Redirections, oder ganz einfache harte oder symbolische Links.

          Was genau möchtest Du also wissen?

          Die Größe aller Resourcen, die ein rekursiver wget-Aufruf auf Deine Festplatte schaufelt? Beliebig groß. Man kann serverseitig dafür sorgen, dass ein Inhalt unter einer beliebigen Anzahl von URLs ausgeliefert wird, ohne dass der Client das erkennen kann.

          Die Größe aller Dateien unterhalb eines bestimmten Verzeichnisses auf dem Server? Das muß mit Betriebssystem-Mitteln auf dem Server ermittelt werden. Siehe mein erstes Posting in diesem Thread.

          Alexander

          --
          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
          1. Was genau möchtest Du also wissen?

            Die Größe aller Resourcen, die ein rekursiver wget-Aufruf auf Deine Festplatte schaufelt? Beliebig groß. Man kann serverseitig dafür sorgen, dass ein Inhalt unter einer beliebigen Anzahl von URLs ausgeliefert wird, ohne dass der Client das erkennen kann.

            Ja, genau das. Die Größe mag zwar in der Theorie beliebig groß sein, ich weiß aber, dass sich die Größe der Dateien nicht ändern wird.

            1. Moin Moin!

              Was genau möchtest Du also wissen?

              Die Größe aller Resourcen, die ein rekursiver wget-Aufruf auf Deine Festplatte schaufelt? Beliebig groß. Man kann serverseitig dafür sorgen, dass ein Inhalt unter einer beliebigen Anzahl von URLs ausgeliefert wird, ohne dass der Client das erkennen kann.

              Ja, genau das. Die Größe mag zwar in der Theorie beliebig groß sein, ich weiß aber, dass sich die Größe der Dateien nicht ändern wird.

              Im HTTP-Kontext gibt es keine Dateien, nur Resourcen. Daher ist die Frage nach Dateigrößen technisch unsinnig. Wenn Du natürlich WEISST, dass alle Resourcen auf dem HTTP-Server einer Datei entsprechen, können wir mal darüber hinwegsehen.

              Es hilft nur ein vollständiger Download. Du kannst einige Abkürzungen nehmen, wenn Du bestimmte Annahmen machen darfst. Für den allgemeinen Fall gelten diese Annahmen NICHT. Daher wird es kein fertiges Programm geben.

              Einige MÖGLICHE Annahmen für einen Apache "out of the box" (NICHT die umkonfigurierten, distributionsspezifischen Varianten) ohne zusätzliche, serverseitige Software:
              * Resourcen, die auf .jpg, .gif, .png, .js, .css, .txt, .mpg, .avi enden (von Query-Parametern mal abgesehen), ignorieren alle URL-Parameter, d.h. unabhängig von URL-Parametern wird immer die selbe Resource ausgeliefert
              * Resourcen, die auf .jpg, .gif, .png, .js, .css, .txt, .mpg, .avi enden, enthalten keine weiteren Links, ihr Inhalt muß also nicht heruntergeladen werden
              * Resourcen, die auf .jpg, .gif, .png, .js, .css, .txt, .mpg, .avi enden, können also mit einem HEAD-Request angefordert werden, um ihre Größe zu ermitteln
              * Die gleichen drei Annahmen gelten für alle per <img src="...">, <embed src="...">, <object src="...">, <sript src="...">, <link rel="stylesheet" src="..."> eingebundenen Resourcen.
              * Keine der Resourcen außer Verzeichnislisten, deren URL mit einem Slash endet, wird durch serverseitige Software generiert (sprich: Keine CGIs, kein PHP, kein JSP/ASP/whatever)
              * Die Größe von Verzeichnislisten ist Null, da hinter den Resourcen keine Datei liegt.
              * Resourcen, die auf .exe, .dll, .asp, .jsp, .php, .cgi enden (wiederum Query-Parameter ignorierend), brechen diese Annahmen und sorgen für einen Programmabbruch ohne Aussage über Größen.

              Mit den Annahmen kannst Du mit relativ wenig Datentransfer die Größe der meisten Dateien hinter dem HTTP-Server ermitteln, in dem Du nur die Resourcen per GET herunterlädst, die Links enthalten können, und von den anderen Resourcen die Größe per HEAD ermittelst.

              Mit Perl und LWP::Simple dürfte der Aufwand bei etwa 50 bis 100 Zeilen liegen.

              Der Einzeiler aus meinem ersten Posting in diesem Thread funktioniert unter diesen Annahmen natürlich auch, schneller und mit wesentlich weniger Transfervolumen.

              Alexander

              --
              Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
              1. Hallo.

                Einige MÖGLICHE Annahmen für einen Apache "out of the box" (NICHT die umkonfigurierten, distributionsspezifischen Varianten) ohne zusätzliche, serverseitige Software:

                [...]

                * Resourcen, die auf .jpg, .gif, .png, .js, .css, .txt, .mpg, .avi enden, enthalten keine weiteren Links, ihr Inhalt muß also nicht heruntergeladen werden

                Zumindest hinsichtlich CSS und vielleicht auch JS dehnst du den Begriff des Möglichen sehr weit.
                MfG, at

                1. Moin Moin!

                  * Resourcen, die auf .jpg, .gif, .png, .js, .css, .txt, .mpg, .avi enden, enthalten keine weiteren Links, ihr Inhalt muß also nicht heruntergeladen werden

                  Zumindest hinsichtlich CSS und vielleicht auch JS dehnst du den Begriff des Möglichen sehr weit.

                  Stimmt. Bei CSS hab ich das definitiv überdehnt, liegt daran, dass ich CSS und erst recht Deko-Bilder nur sehr sparsam einsetze.

                  Bei JS hast Du auch recht. Um aber aus JS *alle* Links zuverlässig zu extrahieren, braucht man zwangsläufig einen JS-Interpreter (oder meinetwegen auch einen Compiler), der das JS im Rahmen der jeweiligen Seite interpretiert. Mit einfachem Pattern matching kommt man da nicht sonderlich weit.

                  wget ignoriert JS definitiv und CSS sehr wahrscheinlich, so dass Resourcen, die nur per CSS oder JS referenziert werden, von wget nicht heruntergeladen werden würden.

                  Alexander

                  --
                  Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                  1. Hallo.

                    liegt daran, dass ich CSS und erst recht Deko-Bilder nur sehr sparsam einsetze.

                    Was du hiermit gleich unter Beweis gestellt hast, hehe. Ansonsten wüsstest du, dass man innerhalb von CSS auch Schriftarten -- jedenfalls theoretisch -- und sogar weitere CSS-Ressourcen einbinden kann.

                    wget ignoriert JS definitiv und CSS sehr wahrscheinlich, so dass Resourcen, die nur per CSS oder JS referenziert werden, von wget nicht heruntergeladen werden würden.

                    Sehr interessant. Danke, das wusste ich noch nicht.
                    MfG, at

        2. Moin Moin!

          Ich habe es jetzt geschafft, die Links mit einem Java Skript alle in eine Textdatei downloaden zu lassen. Leider finde ich nicht heraus, wie man mit Java einen solchen "Head Request" veranlassen kann, ohne gleiche die komplette Resource herunterzuladen.
          Weiß vielleicht jemand, welche Befehle oder welchen Abschnitt der Doku ich mir da anschauen muss?

          Vielen Dank,
          Wtk

          1. Hi,

            Leider finde ich nicht heraus, wie man mit Java einen solchen "Head Request" veranlassen kann, ohne gleiche die komplette Resource herunterzuladen.

            http://www.google.de/search?hl=de&q=java+http+head+request

            MfG ChrisB

            --
            „This is the author's opinion, not necessarily that of Starbucks.“