Browser-imitierendes Script

[MadE]

Hi,

ich wollte mir ein Script schreiben, mit dem ich webseiten aufrufen kann und das dabei für den Server wie ein X-beliebiger Browser aussieht, z.B. Firefox... Die gzip Komprimierung und die meisten der Header Informationen sind ja dabei kein Problem, aber ich hab festgestellt, dass mit urllib2 die Http Requests z.B. mit einem "connection : close" gesendet werden, auch wenn ich es anders angebe... Außerdem ist die Reihenfolge in der die Header gesendet werden anders.

Cookies sollte das ganze am besten auch handhaben können. Im Forum hab ich da schon den Hinweis auf mechanize gefunden, hab aber gerade keine Zeit das im Detail auszuprobieren. Kann mir jemand jetzt schon sagen, ob mechanize mit einem "connection : keep-alive" was anfangen kann? Oder reicht es nicht das als header-info reinzuschreiben und ich muss das irgendwie anders bewerkstelligen?
Aber ich nehm mal an, auch mit mechanize besteht dann noch das Problem der Headerreihenfolge - denn das ist ja in der httplib.

Hat sich überhaupt schon mal jemand Gedanken zu sowas gemach? Oder muss ich dann doch eine selbst modifizierte Version der httplib schreiben?

Gruß

MadE

[Leonidas]

Hallo MadE, willkommen im Forum,

Was willst du eigentlich machen? ``mechanize`` neu erfinden?

[MadE]

nicht falls es nicht unbedingt nötig ist. Wie gesagt, das eigentliche Problem ist, dass ich einen Http Request will, der exakt wie der eines Browsers (IE, Firefox oder von mir aus auch Opera) aussehen soll und wo mir idealerweise das cookie handling abgenommen wird.

Bei dem was ich da bisher an Abfragen über die urllib2 erzeugt hab sind mir eben die zwei Punkte Keep-alive und Headerreihenfolge aufgefallen, wo es in der Hinsicht Unterschiede gibt. In der Mechanize To-Do Liste steht auch noch "Keep-alive / connection caching" (http://wwwsearch.sourceforge.net/mechanize/) d.h. mechanize würde mir ohnehin nur beim cookie handling helfen wie es aussieht - und das mit den cookies scheint sowieso nur das kleinste Problem zu sein. Ich werd mich trotzdem mal eingehender damit beschäftigen, klingt nämlich ansonsten sehr interessant...

zurück zum Thema:
Die Header werden ja in der httplib.py vor dem senden aus einem dictionary gelesen, an der Stelle könnte ich ein paar Zeilen dazuschreiben, die sie vor dem senden anders ordnen. Oder weiß da jemand eine elegantere Lösung? Und bei dem connection caching Problem bin ich relativ ratlos...

[Leonidas]

Die Header werden ja in der httplib.py vor dem senden aus einem dictionary gelesen, an der Stelle könnte ich ein paar Zeilen dazuschreiben, die sie vor dem senden anders ordnen.

Die Reihenfolge in der die Header übertragen werden ist HTTP recht egal.

[MadE]

naja, damit es funktioniert schon, aber wenn der Server ein bisschen genauer hinschaut, dann sieht er "ah, der hat den Host zuletzt im Header stehn, das is mit Sicherheit nicht der Browser, der er vorgibt zu sein, weil der hat den Host immer als Erstes" - oder ist da irgendwo ein Denkfehler?

[EyDu]

Probier mechanize doch einfach aus. Geht auf jeden Fall schneller als alles selbst zu implementieren.

[Darii]

oder ist da irgendwo ein Denkfehler?

Ja, wenn das so genau geprüft wird, dann wird sicherlich auch geprüft, ob Bilder etc. aufgerufen werden. Dazu müsstest du dann die HTML-Datei parsen und auswerten. Nicht zu vergessen eventuelle Javascripts und und und.

[Leonidas]

naja, damit es funktioniert schon, aber wenn der Server ein bisschen genauer hinschaut, dann sieht er "ah, der hat den Host zuletzt im Header stehn, das is mit Sicherheit nicht der Browser, der er vorgibt zu sein, weil der hat den Host immer als Erstes" - oder ist da irgendwo ein Denkfehler?

Kein Browser garantiert dass die Header immer in der selben Reihenfolge abgechickt werden.

[birkenfeld]

naja, damit es funktioniert schon, aber wenn der Server ein bisschen genauer hinschaut, dann sieht er "ah, der hat den Host zuletzt im Header stehn, das is mit Sicherheit nicht der Browser, der er vorgibt zu sein, weil der hat den Host immer als Erstes" - oder ist da irgendwo ein Denkfehler?

Kein Browser garantiert dass die Header immer in der selben Reihenfolge abgechickt werden.

Und doch wird es in praxi immer so sein.

[Leonidas]

naja, damit es funktioniert schon, aber wenn der Server ein bisschen genauer hinschaut, dann sieht er "ah, der hat den Host zuletzt im Header stehn, das is mit Sicherheit nicht der Browser, der er vorgibt zu sein, weil der hat den Host immer als Erstes" - oder ist da irgendwo ein Denkfehler?

Kein Browser garantiert dass die Header immer in der selben Reihenfolge abgechickt werden.

Und doch wird es in praxi immer so sein.

In einer Version eines Browsers vielleicht, aber in der nächsten? Besonders bei so seltsamen Konstrukten wie IE, der je nach Standardkonformität verschiedene Bugs aufweist.

Das ist ja ähnlich sinnlos, wie dass man erwartet, dass in einer XML-Datei die Attribute in einem Tag immer in der selben Reihenfolge sind.

[birkenfeld]

Ich hab hier nicht von sinnvoll oder nicht gesprochen, sondern davon, dass mit nicht geringer Wahrscheinlichkeit solche Kennzeichen bei Browsern auch über mehrere Versionen gleich bleiben -- und sowas wird ausgenutzt.

[lunar]

Ich hab hier nicht von sinnvoll oder nicht gesprochen, sondern davon, dass mit nicht geringer Wahrscheinlichkeit solche Kennzeichen bei Browsern auch über mehrere Versionen gleich bleiben -- und sowas wird ausgenutzt.

Von wem denn? Ohne jetzt irgendeine Meinung dazu zu haben, interessiert mich gerade einfach mal, wer so krank ist und Client-Identifizierung anhand der Header-Reihenfolge betreibt ...

[MadE]

So... endlich Wochenende... Zeit auch mal was auszuprobieren

Ja, wenn das so genau geprüft wird, dann wird sicherlich auch geprüft, ob Bilder etc. aufgerufen werden. Dazu müsstest du dann die HTML-Datei parsen und auswerten. Nicht zu vergessen eventuelle Javascripts und und und.

Naja, die Bilder könnten ja im Browsercache liegen, dann werden sie auch nicht nachgeladen, das ist also kein zuverlässiges Kriterium... und bei Javascript müsst man auch "nur" auf http requests achten, alles andere hat mit dem Server ja erstmal nichts zu tun.

und was meinst du mit "und und und"? so viel fällt mir nicht mehr ein. Java und Flash vielleicht, aber das würd ich vorerst außer Acht lassen. Braucht man schließlich nicht für jede Webseite und ist ja auch nicht defaultmäßig in den Browsern drin...

Ohne jetzt irgendeine Meinung dazu zu haben, interessiert mich gerade einfach mal, wer so krank ist und Client-Identifizierung anhand der Header-Reihenfolge betreibt

Naja, keine direkte Client-Identifizierung vielleicht, aber wenn man herausfinden will, ob eine Seite wirklich per Browser oder von einem Skript aufgerufen wurde, dann wäre das für mich zumindest eine der naheliegendsten Methoden neben der Headerinformation selbst, die ja sehr einfach geändert werden kann. (wow, was für ein Satz) Und viel mehr als eine Tabelle mit der man vergleicht braucht man ja dafür auch nicht, wäre also nicht mal sehr aufwändig das Ganze. Oder wie würdest du es machen? Vielleicht kennt birkenfeld ja sogar ein konkretes Beispiel, wo sowas gemacht wird

Für diejenigen, die vielleicht die gleichen Sorgen haben wie ich; ich habe inzwischen das hier gefunden: http://linux.duke.edu/projects/urlgrabb ... alive.html

Werd damit und mit mechanize mal ein bisschen rumprobiern... mal sehn was dabei rauskommt.

[lunar]

Ohne jetzt irgendeine Meinung dazu zu haben, interessiert mich gerade einfach mal, wer so krank ist und Client-Identifizierung anhand der Header-Reihenfolge betreibt

Naja, keine direkte Client-Identifizierung vielleicht, aber wenn man herausfinden will, ob eine Seite wirklich per Browser oder von einem Skript aufgerufen wurde, dann wäre das für mich zumindest eine der naheliegendsten Methoden neben der Headerinformation selbst, die ja sehr einfach geändert werden kann.

Die Existenz von Erweiterungen wie User Agent Switcher für den Firefox allein ist schon Grund genug, Header nicht zur Identifizierung eines Browsers zu verwenden. Die kann man nämlich fälschen, und eine RFC-inkompatible Seite, die die Reihenfolge der Header auswertet, ist geradezu prädestiniert für Bugs, weil Browser-Erweiterungen oder Patches die Reihenfolge der Header ändern.

Und viel mehr als eine Tabelle mit der man vergleicht braucht man ja dafür auch nicht, wäre also nicht mal sehr aufwändig das Ganze. Oder wie würdest du es machen?

Angesichts der Vielzahl der Browser ist mit der Erstellung dieser "Tabelle" viel Aufwand verbunden, und die gewonnenen Daten sind wahrscheinlich nicht mal zuverlässig. Selbst wenn man nur die vier verbreiteten Desktop-Browser erkennen will, hat man schon viel zu tun: IE6, IE7, Firefox 2 und 3, Opera 8 und 9, Safari. Die ganzen anderen Browser wie Konqueror, Ephany, etc. mal außen vorgelassen, und von den Embedded-Browsern gar nicht zu reden (da backt jeder Hersteller sein eigenen Browser). Vergiss nicht, wir reden hier nicht über Rendering-Engines (deren Zahl eher überschaubar ist), sondern über die Browser selbst (die wie Sand am Meer existieren).

[MadE]

ok, das überzeugt mich... damit wären alle Probleme ja so weit gelöst =D Das keep-alive funktioniert nämlich über den Code im oben genannten Link. So... dann werd ich mich mal ans programmieren machen...

Danke!