Ich crawle eine Seite über LWP::UserAgent. Problem ist, dass die Seite von Cloudflare "beschützt" wird, und dass ich die Verbindung bei Vorhandensein eines Tor Connectors auf Port 9050 gerne über diesen Connector (SOCKS-Proxy) laufen lassen will, denn dann bekomme ich als Antwort vom Server nur einen 403 Forbidden. Ohne SOCKS-Proxyverbindung bekomme ich normale 200 OK.

Der interessante Teil - wo auch der Bezug zu Perl deutlich wird - ist wenn ich den Port statt auf 9050 auf 9150 setze. Auf dem Port hört nämlich der dem Tor Browser Bundle zugehörige Tor Connector, weil Port 9050 bereits von einem eigenen Dienst belegt wird - warum der Browser nicht einfach 9050 nimmt, anstatt eine Instanz seiner eigenen Software auf Port 9150 zu starten, braucht man mich nicht fragen. Jedenfalls senden jetzt mein Script und mein Browser ihre Anfragen beide über den 9150-Connector, verwenden also nach meinem Verständnis den gleichen Exitnode - und im Browser klappts reproduzierbar. Sogar mit abgeschaltetem Javascript. Das Script klappt nicht.

Also habe ich mir mal den Request im Browser und im Script genauer angeschaut und habe dabei Unterschiede in der Statuszeile festgestellt:
1. Der Browser sendet als HTTP-Version 2.0 mit, das Script sendet keinerlei Protokollversion mit.
2. Der Browser teilt die angefragte URL in Domain und Resource, packt die Domain in einen eigenen Host-Header, und die Resource in die Statuszeile. Das Script packt einfach die URL - samt Protokollkürzel - in die Statuszeile.

Wenn ich also nach https://example.org/example.png suche, sendet das Script:


, und der Browser sendet:


Dies - und die Reihenfolge, in die die Header gesendet werden - sind die einzgen Unterschiede, die ich in den Requests festmachen kann. Ansonsten sende ich die gleichen Browser-ähnlichen Header wie auch im Browser, und erhalte trotz gleichem Tor-Connector einen 403 statt einen 200.

Jetzt bin ich mir relativ sicher, dass dieses Verhalten neu ist; ich habe vor Jahren (2013 ~ 2014) bereits mit LWP::UserAgent gearbeitet und bin mir ziemlich sicher, dass das Paket sich bezüglich der Statuszeile verhalten hat wie der Browser (wobei LWP::UserAgent dabei noch einen bescheuerten TE-Header oder so mitgesendet hat, den man explizit in der PM-Datei auskommentieren musste, denn ich habe Seiten gesehen, die darauf geprüft haben und den UserAgent als Bot erkannt hatten). Ich bin mir deswegen so sicher, weil ich über diese Ausgaben HTTP gelernt habe. Ich bin mir ebenfalls relativ sicher, dass ich vor Monaten bereits eines anderen Scriptes wegen laut fluchend den Code debuggt habe, weil mir andere, von Cloudflare "geschützte" Seiten immer wieder 403 zurückgegeben haben und ich irgendwann noch lauter fluchend darauf gekommen bin, das Script in solchen Fällen in 10-sekündigen Schlaf zu senden und in der Zwischenzeit den Tor-Connector neuzustarten.

Funktioniert hier aber auch nicht, und durch den LWP-Code wühle ich mich erst, wenn klar geworden ist, dass LWP::UserAgent absichtlich mit älteren Versionen bricht und die auch keinen "Kompatibilitätsmodus" oder so haben, mit dem man das alte Splitting wieder herstellen kann. Dann werde ich halt bis nach Geilenkirchen hörbar fluchend das alte Verhalten für meine lokale Kopie wiederherstellen.

Ach ja, nur der Vollständigkeit halber: ja, ich setze auch den HTTP-UserAgent auf den gleichen String wie in meinem Browser, und wenn ich Proxies zwingend deaktiviere, bekomme ich auch wieder 200, und ich sehe nicht, wie das ein Tor-Problem sein könnte, wenn's im Tor Browser tut. Und auf Tor würde ich ungerne verzichten, weil das Script nicht schnell arbeiten braucht und es die NSA ärgert.
Last edited: 2020-09-16 14:18:58 +0200 (CEST)