Fehlersuche in Modulen DasOertliche, 11880, DasTelefonbuch und Gelbeseiten

Hallo an die Community! 🙂

Erstmal herzlichen Dank an den Entwickler für diese wirklich hilfreiche Software!

Leider funktionierte bei mir schon seit längerem die Rückwärtssuchen des DasÖrtliche-Moduls nicht mehr, daher habe ich mal ein paar andere geladen. Folgende waren installiert:

http://www.DasOertliche.de
11880.com
DasTelefonbuch.de
Gelbeseiten.de

Aber auch die neu geladenen funktionierten nicht. Da ich ein wenig PHP kann und selbst schon einmal einen Scraper schrieb, habe ich als erstes begonnen, die Regex der Module zu verändern, da ich bemerkt hatte, dass sich die HTML-Strukturen, zumindest bei 11880.com und DasTelefonbuch, ggf. verändert hatten. Jedoch brachten diese Anpassungen keinen Erfolg.

Zum Vergleich habe ich die Anfragen auch immer mal im Browser ausgeführt, auch um zu sehen, bei welcher URL ich am Ende lande. Dabei habe ich festgestellt, dass die neu geladenen Module auf SSL (also zu https) umleiten. Eine entsprechende Änderung der Abfrage-URL´s in den Einstellungen blieb ebenfalls erfolglos. Irgendwann funktionierte jedoch http://www.DasOertliche.de (die einzige Seite, die noch komplett über http läuft) nachdem ich bei allen Modulen das Zeichen-Offset (timeout?) um 100% erhöht hatte (also von 8.096 auf 16.192).

Mittlerweile glaube ich aber (u.a.) folgenden Fehler ausgemacht zu haben. Wie gesagt läuft nur http://www.DasOertliche.de über http und das wichtigste dabei ist: die URL bleibt, inkl. der angehängten GET-Parameter, die gleiche. Um eine derartige Umleitung in PHP zu berücksichtigen, hätte eine CURL-Option wie folgt ausgesehen:

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);

Wenn ich richtig recherchiert habe, müsste die entsprechende Option in Java wie folgt gesetzt werden:

con.setInstanceFollowRedirects(true);

Könnte es sein, dass diese (oder eine ähnliche) Zeile im Quellcode fehlt?

Übrigens: 11880.com scheint offenbar zu bemerken, dass es sich NICHT um einen Standard Browser handelt, der den Request absetzt, denn es gibt laut den logs ein 301 Moved Permanently zurück – nicht aber bei normaler Browseranfrage. Wie das programmatisch in Java zu vermeiden ist, entzieht sich meiner Kenntnis (wie gesagt – bin kein Java-Mensch), ich bin mir aber recht sicher, dass es lösbar ist (in PHP wäre es das zumindest).

Bei DasTelefonbuch tut sich rein gar nichts. Die Seite scheint möglicherweise auch zu erkennen, dass es es sich um einen Scraper/Sniffer, also nicht um einen User-gesteuerten Browser handelt. Es wird nicht einmal ein Repository in den logs dafür angelegt. Wo genau der Prozess abbricht, kann ich nicht sagen – ich vermute, dass schon der CURL nicht ausgeführt werden kann, sonst würde es ja zumindest den HTML-Response (z.B. einen 301 wie bei 11880.com) aus dem DOMDocument laden (so heißt es zumindest in PHP …).

Zum Schluss noch etwas Kritik an den Logs – wenn ich darf 🙂 . Die könnten etwas aufschlussreicher sein. Mir waren die jedenfalls keine Große Hilfe bei der Suche nach den Fehlern, allerdings hatte ich evtl. auch nicht das umfangreichste Error-Reporting eingeschaltet, sondern nur jamlogger.trace.level=INFO – ich meine, irgendwo gelesen zu haben, dass es noch eine Option für einen ausführlicheren Log gibt?

Ich hoffe, ich konnte dazu beitragen, dass die Module zu gegebenem Zeitpunkt erfolgreich überarbeitet werden können.

Mit besten Grüßen, John