TEmbeddedWB + MultiProxy

[Thom]

Ich sehe: Ihr wart heute fleißig!

Ja, die Indy's...

Um das mal kurz zusammenzufassen:
Die Komponente TIdHTTPServer zerlegt - mehr oder weniger gut - die Anfrage in seine Bestandteile. Fehler werden definitiv beim Parsen der Kekse gemacht (das hatte ich schon weiter vorn im Listing erwähnt).
Die Komponente TIdHTTP macht aus den Einzelteilen, mit der sie initialisiert wird, wieder eine neue Anfrage. Aber leider werden auch hier Fehler gemacht (siehe Problem mit Content-Encoding und - wahrscheinlich - dem CharSet).

Dieses Zerlegen und anschließende Zusammenfügen ist zwar unheimlich flexibel - wenn da nicht so viele Fehlerquellen wären.
Normalerweise sollte ein Proxy die Daten unverändert in beide Richtungen durchschaufeln - nicht mehr und nicht weniger.
OK: Diese Aufgabe erledigt die Komponente TIdHTTPProxyServer - nur eben ohne merklicher Einflußmöglichkeit durch den Programmierer.

Nach den bisherigen Tests bin ich mit keiner der Lösungen richtig glücklich.
Bugs in den Indy-Units auszubügeln ist schwierig, da die mit Delphi gelieferten Versionen extrem schlecht und nur mit viel Aufwand neu compilierbar sind (zumindest unter XE).

Deshalb habe ich in den letzten zwei Tagen einen neuen Proxy - basierend auf Indy-Komponenten - geschrieben, der einerseits keine Daten verschluckt und andererseits wesentlich flexibler als die mitgelieferte Komponente ist.

Erste Tests laufen ganz gut: Google wird korrekt mit den deutschen Umlauten angezeigt und Flash funktioniert. Selbst hier im Forum kann ich gut navigieren. Bei dieser Gelegenheit stellte ich fest, daß etliche Bilder vorgeben, Gif's zu sein, obwohl sie in Wahrheit Jpeg's sind...
Allerdings wird momentan noch kein Streaming unterstützt. Windows 7 konnte ich leider noch nicht testen.

Allerdings benötige ich noch eine kleine Weile für Tests und den Einbau weiterer Features.

[AndreFM]

Zitat von Thom:

Erste Tests laufen ganz gut: Google wird korrekt mit den deutschen Umlauten angezeigt und Flash funktioniert. Selbst hier im Forum kann ich gut navigieren. Bei dieser Gelegenheit stellte ich fest, daß etliche Bilder vorgeben, Gif's zu sein, obwohl sie in Wahrheit Jpeg's sind...
Allerdings wird momentan noch kein Streaming unterstützt. Windows 7 konnte ich leider noch nicht testen.

Allerdings benötige ich noch eine kleine Weile für Tests und den Einbau weiterer Features.

Hi Thomas,
Hast du eigentlich mit anderen Komponenten versuch? (Clever Internet Suite, etc.) Das einzige Problem ist das es nicht Frei ist aber die haben ein Trial zum Testen. Bin gerade dabei mein notebook zu updaten und da es ein oder zwei Tage dauern wird, werde erst später das testen. Nur um zu sehen wie es sich verhält. Aber hast du das letzte version von Indy benutzt (download via SVN) oder benutzt du das Indy die mit Delphi mit geliefert wird? Vielleicht sind da schon einige Verbesserungen.
Also, falls du Hilfe brauchst mit testen unten Win 7 und Englisch OS, schicke mir ein email, du wirst es haben
Gruss,
André (von Sydney)

[Thom]

Hallo André,
viele Grüße zurück nach Sydney!
Weshalb vergeht die Zeit nur immer so schnell!?

Ich hatte in den letzten 14 Tagen mit den Indy-Quelltexten gekämpft und mich in einem Schnellkurs in die Grundlagen der HTTP-Kommunikation eingearbeitet.

Heute also die ersten Ergebnisse dieser Anstrengungen.
Mit einem Proxy kann man (fast) alles machen - aber auch schnell ziemlich viel falsch.

Ich möchte deshalb einige grundlegende Überlegungen zum Proxy an einem Beispiel demonstrieren.

Wer hat schon einmal versucht, die Google-Seite auf Englisch zu sehen? Das sollte eigentlich kein Problem sein: http://www.google.com.
Interessanterweise landet man dann sofort auf der deutschen Seite google.de.
Ein Service? Das wollte ich doch aber gar nicht!!!

Ok. Erster Versuch mit dem Proxy:



Den Eintrag Accept-Language auf he eingestellt (1.) - zur Kontrolle die Header angeschaut (2.) - stimmt. Und schon kann die Maus Hebräisch.



Zweiter Versuch mit Accept-Language auf en (2.) - Kontrolle der Header (3.): stimmt. Kekse sicherheitshalber aus (4.) und ab zu google.com (1.).
Als Reaktion erhält man von Google die interessante Antwort, daß die Seite angeblich verschoben wurde (5.). Achso!?
Und als Folge davon kommt die Weiterleitung auf google.de (6.). Damit ist also klar, weshalb man Google nicht auf Englisch zu sehen bekommt.

Bleibt die Frage, wie Google erkennt, daß ich aus Deutschland komme. An der HTTP-Anfrage kann es nicht liegen - die Header wurden entsprechend korrigiert und verräterische Cookies vor der Übertragung gelöscht. Ein JavaScript wurde auch nicht geladen. Wertet Google eventuell die IP-Adresse aus!?

Nächster Versuch mit einem weiteren, nachfolgenden Proxy aus dem Internet (1.):



Und siehe da: Wie durch ein Wunder kommt die erwartete Antwort vom Server (2.) und die gewünschte Seite (3.).

Also wertet Google offenbar doch die IP des Computers aus (ich lasse mich natürlich gern eines Besseren belehren)!?.
Dazu etwas Stoff für Paranoiker: Wer nicht weiß, wo er wohnt...
In diesem Zusammenhang eine lustige Sache: Diese Seite, die so für Anonymität im Internet plädiert, wertet die Besucher gleich mal schnell durch Google-Analytics aus (1. und 2.)...



Natürlich gibt es Firewalls, Plugins für Browsers und eine Menge anderer Tools, die für ein tolles Gefühl an Sicherheit und Anonymität sorgen - trotzdem ist es sehr interessant, einmal hinter die Kulissen zu schauen, um wieder mal etwas aus der Traumwelt aufzuwachen.

Dazu bietet sich ein Proxy an, mit dessen Hilfe man die volle Kontrolle über den aus- und eingehenden Datenverkehr einer TWebBrowser-Komponente erhält. Die Indy-interne Komponente TIdHTTPProxyServer bietet eine Ausgangsbasis, die aber für eine vernünftige Handhabung erweitert werden muß. Einen möglichen Ausgangspunkt für eigene Experimente bietet die Komponente THTTPProxyServer auf Basis der Indy's.

Sie besitzt vier Ereignishandler:

1. OnCommand: Vom Klienten ist eine Anfrage eingetroffen. Die Anfrage inklusive aller Header und Cookies kann modifiziert und mit eigenen Werten versehen werden. Es ist auch möglich, die Anfrage abzubrechen und beliebige Daten an den Klienten zurückzusenden. Der Proxy würde dann quasi als HTTP-Server arbeiten. Damit wäre zum Beispiel auch die Arbeit mit Black- und Whitelists möglich, Cookies könnten unterdrückt und weitere Proxys vorgeschaltet werden.
2. OnResponse: Vom Server ist die Antwort eingetroffen. Auch an dieser Stelle können alle Einträge im Header einschließlich der vom Server stammenden Cookies bearbeitet werden.
3. OnDocument: Die vom Server angeforderten Daten (HTML-Seite, Bilder, ....) sind eingetroffen. Diese liegen in einem Memory-Stream vor und können auch bearbeitet werden. Hier gibt es allerdings (momentan noch) eine kleine Einschränkung: Wird der Inhalt gestreamt, wird dieses Ereignis nicht ausgelöst. Das ist aber in Arbeit.
4. OnLog: Die Komponente THTTPProxyServer besitzt einen internen Log-Mechanismus. Ist die Eigenschaft Logging auf true gesetzt (standardmäßig false), wird nach der Abarbeitung der Klientanfrage dieses Ereignis im Kontext des Hauptthreads ausgelöst und kann so bedenkenlos zur Ausgabe von Informationen genutzt werden.

Delphi-Quellcode:

procedure TForm1.OnLog(Sender: TObject; LogItem: TLogItem);
begin
  with ListView1.Items.Add do
  begin
    Caption:=LogItem.Request.Command;
    Data:=LogItem;
    SubItems.Add(IntToStr(LogItem.Response.Code));
    SubItems.Add(LogItem.Response.ContentType);
    SubItems.Add(LogItem.Request.Host);
    SubItems.Add(LogItem.Request.Path);
    SubItems.Add(LogItem.Request.Document);
    SubItems.Add(LogItem.Request.Params);
  end;
end;

Die Komponente ist noch im absoluten Anfangsstadium - inklusive etlicher Baustellen und Bugs...
Viel Spaß bei eigenen Experimenten!

P.S.: Mir ist bekannt, daß ich auch auf der deutschen Google-Seite Englisch als Oberflächensprache einstellen kann (das geht dann per Cookie). Mir ging es aber um eine Klärung der Frage, wie ich auf google.com gelangen und auch dort bleiben kann, ohne gleich wieder weggeschickt zu werden.

[N.Hinterseer]

I am not sure if this will work with HTTPS ?

[PeterPanino]

Zitat von Thom:

Ok - da will ich mal nicht so sein...

Delphi-Quellcode:

function SetProxy(Server: String): Boolean;                //Server z.B. '127.0.0.1:8080' oder ''
[...]
end;

Hallo Thom! Ich habe versucht, diesen Code in Delphi XE8 zu compilieren und habe dabei natürlich einige Fehlermeldungen und Warnungen des Compilers erhalten:

Delphi-Quellcode:

OptionsList.pOptions^.Value.pszValue := PChar(Server);
// [dcc32 Error] MainForm.pas(361): E2010 Incompatible types: 'PAnsiChar' and 'PWideChar'

(Agent), INTERNET_OPEN_TYPE_DIRECT, nil, nil, 0);
// [dcc32 Warning] MainForm.pas(369): W1044 Suspicious typecast of string to PAnsiChar
// [dcc32 Error] MainForm.pas(369): E2010 Incompatible types: 'PWideChar' and 'PAnsiChar'

Gibt es eine aktuellere Version dieser Funktion oder soll ich einfach PAnsiChar/PWideChar berichtigen?

[DeddyH]

Definier doch einfach die Direktrive
{$DEFINE DELPHI2009_UP} , die wird ja abgefragt.

[PeterPanino]

Hallo DeddyH!

Vielen Dank, klappt!

Da ich bestimmte Websites hintereinander in TWebBrowser aufrufe, schien es zuerst nicht zu klappen. Aber offenbar gibt es durch den Proxy Server eine Verzögerung von bis zu 5 Sekunden. (Ist das normal?). So habe ich die Intervalle zwischen den Aufrufen vergrößert, und jetzt scheint es zu klappen.

Gibt es irgendwo eine Liste von internationalen Proxy Server IPs, die verlässlich auch für längere Zeit funktionieren und eine nicht zu große Verzögerung haben?