|
|
 Up |
|
|
  |
Author: Sebastian G.Sebastian G. Date: Sep 13, 2007 14:28
Einfache Geschichte: Archive.org archiviert alte Webseiten.
Die URL-Syntax ist
http://web.archive.org/web/datum/http://www.originalseite.de, ausgeliefert
wird die originale Webseite, ergänzt um einen Footer, der zumindest
dynamisch für den Browser mittels DOM an jeden Link (Anchor, Image, Object)
das " http://web.archive.org/web/datum/http://" vorne dranhängt. Ferner wird
in den Header noch ein BASE-HREF gepackt, der auf die Originalwebseite verweist.
Und jetzt will das jemand crawlen, mit Wget oder Httrack.
Das Problem: Die können kein JavaScript, und bieten auch keine Option, die
URLs anderwaltig umzuschreiben. Zudem kommt Wget mit dem doppelten "http://"
in der URL nicht klar.
Meine Lösung wäre ein Header-Rewrite, optional mit einer DNS-Manipulation.
Nur irgendwie krieg ich das nicht recht hin.
Privoxy geht irgendwie nicht, und selbst wenn, es wird der Server aufgelöst,
bevor der Request abgeht, d.h. es würde die umgeschriebene URL mitsamt
"Host: web.archive.org" an den Server der Originalwebseite geschickt. Um
umgebogener DNS-Auflösung ist geht das schon etwas besser, nur scheint man
dort den GET-Request nicht mehr umschreiben zu können, es kommt immer ein
"Could not get regex filter state".
|
| Show full article (2.29Kb) |
|
| | 5 Comments |
|
|
Author: Lukas GrafLukas Graf Date: Sep 14, 2007 13:41
Sebastian G. wrote:
> Und jetzt will das jemand crawlen, mit Wget oder Httrack.
>
> Das Problem: Die können kein JavaScript, und bieten auch keine Option, die
> URLs anderwaltig umzuschreiben.
Stimmt.
> Zudem kommt Wget mit dem doppelten "http://" in der URL nicht klar.
Das hingegen stimmt nicht. Wenn der URL korrekt gequotet wird (in der Bash
mit einfachen Anführungsstrichen), hat wget damit keinerlei Probleme. Falls
das bei dir nicht klappt, hast du den URL nicht richtig geqoutet, oder die
Shell deines OS macht Blödsinn.
> Hat jemand 'ne Idee, was wo schiefgegangen ist oder wie man das anders
> angehen könnte? Oder wo ich sonst mal nachfragen könnte?
Statt mit Proxies, umbiegen von DNS, rewrite rules etc. würde ich das viel
eher "von Hand" scripten. Also die Rekursion z.B. in Bash oder Python
selbst schreiben, unter Zuhilfenahme von wget oder auch curl. Sollte mit
einer Handvoll Zeilen zu erledigen sein, und dann hast du dafür feine
Kontrolle über deinen Crawler.
|
| Show full article (1.68Kb) |
|
| | no comments |
|
|
Author: Sebastian G.Sebastian G. Date: Sep 14, 2007 15:05
Lukas Graf wrote:
> Sebastian G. wrote:
>
>> Und jetzt will das jemand crawlen, mit Wget oder Httrack.
>>
>> Das Problem: Die können kein JavaScript, und bieten auch keine Option, die
>> URLs anderwaltig umzuschreiben.
>
> Stimmt.
>
>> Zudem kommt Wget mit dem doppelten "http://" in der URL nicht klar.
>
> Das hingegen stimmt nicht. Wenn der URL korrekt gequotet wird (in der Bash
> mit einfachen Anführungsstrichen), hat wget damit keinerlei Probleme. Falls
> das bei dir nicht klappt, hast du den URL nicht richtig geqoutet, oder die
> Shell deines OS macht Blödsinn.
Nein, es liegt daran, daß der Dateisystem-Filter von Wget meint, daß der
Doppelpunkt im Dateinamen nicht OK sei, zum anderen will es den auch nicht
ersetzen.
|
| Show full article (2.16Kb) |
| no comments |
|
|
Author: Lukas GrafLukas Graf Date: Sep 15, 2007 08:02
Sebastian G. wrote:
> Nein, es liegt daran, daß der Dateisystem-Filter von Wget meint, daß der
> Doppelpunkt im Dateinamen nicht OK sei, zum anderen will es den auch nicht
> ersetzen.
>> Also die Rekursion z.B. in Bash oder Python selbst schreiben,
>> unter Zuhilfenahme von wget oder auch curl.
>
> Also das, was ich eigentlich vermeiden wollte.
Warum? Aufwand kanns ja nicht sein, mit all dem was du schon versucht hast,
hast du doch sicher mehr Zeit verbracht als du brauchen würdest um das selbst
zu implementieren.
> Mit dem speziellen URL-Schema hapert es da allerdings.
Wobei der URL eigentlich nach RFC 1738 auch nicht gültig ist, wenn ich das
richtig verstehe:
| Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
| reserved characters used for their reserved purposes may be used
| unencoded within a URL.
|
| Show full article (2.12Kb) |
| no comments |
|
|
Author: Sebastian G.Sebastian G. Date: Sep 16, 2007 03:36
Lukas Graf wrote:
> Sebastian G. wrote:
>
>> Nein, es liegt daran, daß der Dateisystem-Filter von Wget meint, daß der
>> Doppelpunkt im Dateinamen nicht OK sei, zum anderen will es den auch nicht
>> ersetzen.
Mit wget -x allerdings nicht. Zumindest nicht, bis ich deinen unter
beschriebenen Vorschlag umgesetzt hatte.
>> Am einfachsten wäre es daher m.E., ihn einfach auf die Original-URL
>> crawlen zu lassen und auf Proxy-Level einfach die archive.org-URL vorne
>> dranzugängen. >
> Von hinten durch die Brust ins Auge?
Ich würde es eher als strukturierten Ansatz betrachten, um genau das
umzudrehen, was archive.org umsetzt.
|
| Show full article (1.35Kb) |
| no comments |
|
|
|
|
|
Author: Thomas PThomas P Date: Oct 4, 2007 13:43
Am 15.09.2007 00:05 schrieb Sebastian G.:
> Das Hauptproblem ist ja, bereits vor dem Crawlen bereits gecrawlte URLs
> auszunehmen.
Wenn durch das Crawlen der URLs Dateien erzeugt wurden, kannst du diese
mit der Option -nc (--no-clobber) überspringen.
|
| |
| no comments |
|
|
