| Autor |
Beitrag |
Klabautermann
  
Beiträge: 6366
Erhaltene Danke: 60
Windows 7, Ubuntu
Delphi 7 Prof.
|
Verfasst: Fr 27.06.08 11:59
Hallo,
ich möchte gerne per HTTPS mit der API eines Internetdienstleisters kommunizieren. Interessanterweise funktioniert das beim Aufruf eines seiner Dienste, bei anderen bekomme ich aber immer eine 301 (Moved Permanently) Fehlermeldung. Die Kommunikation wird von einer Funktion in der Basisklasse übernommen, von der sowohl die Klasse für Service 1 als auch die für Service 2 Abgeleitet sind. Sprich beide Anfragen werden von der Gleichen Funktion gepostet. Um dem Problem auf die Schliche zu kommen habe ich die nicht funktionierende Anfrage auch einmal als GET-URL aufbauen lassen und in einem alten FireFox (Version 1 welche noch SSL2 unterstützt) aufgerufen, dort bekomme ich das gewünschte Ergebnis zurück gemeldet. Rufe ich die selbe Adresse mit den selben Parametern über meine Indy (10) Komponente ab, so erhalte ich wieder eine 301. Auch der Anbieter des Internetdienstes kann sich nicht erklären, warum meine Anfragen (und nur meine) immer umgeleitet werden.
Also habe ich weiter auf der Spurensuche einmal meine eigene Anfrage sowie die vom FireFox mit dem WireShark Protokolliert und folgendes Ergebnis erhalten (IP QQQ.QQQ.QQQ.QQQ = Quelle = Mein System / IP: ZZZ.ZZZ.ZZZ.ZZZ = Ziel = Server des Dienste Anbieters):
Meine Anwendung:
  Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
| No. Time Source Destination Protocol Info
62 5.309366 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP x9-icue > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
63 5.388487 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > x9-icue [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1416
64 5.388532 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP x9-icue > https [ACK] Seq=1 Ack=1 Win=65535 Len=0
65 5.389447 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Client Hello
66 5.469525 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > x9-icue [ACK] Seq=1 Ack=52 Win=5840 Len=0
67 5.471917 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Server Hello
68 5.472839 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Client Master Key
69 5.556567 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data
70 5.556617 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Encrypted Data
71 5.636375 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data
72 5.636799 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Encrypted Data
73 5.723212 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data, Encrypted Data
74 5.723230 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > x9-icue [FIN, ACK] Seq=1840 Ack=574 Win=7504 Len=0
75 5.723258 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP x9-icue > https [ACK] Seq=574 Ack=1841 Win=65535 Len=0
76 5.724120 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP x9-icue > https [FIN, ACK] Seq=574 Ack=1841 Win=65535 Len=0
77 5.803390 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > x9-icue [ACK] Seq=1841 Ack=575 Win=7504 Len=0 |
FireFox 1:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
| No. Time Source Destination Protocol Info
3 0.032319 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP metasage > https [SYN] Seq=0 Win=64240 Len=0 MSS=1460
4 0.112393 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > metasage [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
5 0.112577 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP metasage > https [ACK] Seq=1 Ack=1 Win=64240 Len=0
6 61.889230 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Client Hello
7 61.889230 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > metasage [ACK] Seq=1 Ack=46 Win=64240 Len=0
8 61.970150 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Server Hello
9 61.972579 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Client Master Key
10 61.972857 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > metasage [ACK] Seq=917 Ack=186 Win=64240 Len=0
11 62.055818 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data
12 62.056359 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Encrypted Data
13 62.056529 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > metasage [ACK] Seq=952 Ack=221 Win=64240 Len=0
14 62.136614 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data
15 62.137154 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Encrypted Data
16 62.137392 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > metasage [ACK] Seq=987 Ack=825 Win=64240 Len=0
17 62.375218 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data, Encrypted Data, Encrypted Data, Encrypted Data, Encrypted Data
18 62.375444 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data, Encrypted Data, Encrypted Data, Encrypted Data, Encrypted Data
19 62.375525 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP metasage > https [ACK] Seq=825 Ack=1465 Win=64240 Len=0
20 69.667921 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ SSLv2 Encrypted Data
21 69.668131 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP https > metasage [ACK] Seq=1465 Ack=1200 Win=64240 Len=0
22 69.773120 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data,
23 69.774293 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP [TCP segment of a reassembled PDU]
24 69.774293 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP metasage > https [ACK] Seq=1200 Ack=4297 Win=64240 Len=0
25 69.775720 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ TCP [TCP segment of a reassembled PDU]
26 69.853242 ZZZ.ZZZ.ZZZ.ZZZ QQQ.QQQ.QQQ.QQQ SSLv2 Encrypted Data
27 69.853398 QQQ.QQQ.QQQ.QQQ ZZZ.ZZZ.ZZZ.ZZZ TCP metasage > https [ACK] Seq=1200 Ack=6069 Win=64240 Len=0 |
Die Hinterlegten Zeilen sind die, die sich (nach meinem DIF Tool) in wesentlichen Punkten unterscheiden. Was mich überrascht, ist das der Server, mehr Messages an den FireFox richtet (Zeile 9 & 12 im FF Protokoll) als an meine Anwendung. Leider bin ich in Netzwerkfragen nicht Firm genug um mir erklären zu können warum das so ist, und was ich anders machen kann damit der Server auch meine Anfragen richtig bearbeitet.
Kann mir jemand von euch auf die Sprünge helfen?
//Edit: Die beiden zusätzlichen Servermeldungen an den FireFox sind Acknowledgements, akzeptiert der Server mein Zertifikat nicht? Und wenn das so ist, wie kann es es mir Verschlüsselt mitteilen? Dafür müsste er es doch nutzen?
Gruß
Klabautermann
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Fr 27.06.08 12:30
301 ist in dem Sinne kein Fehler (4xx und 5xx wären Fehler), sondern lediglich der Hinweis des Servers, dass die angegebene URL an eine andere Stelle umgezogen ist. Der Firefox führt diese Umlenkung automatisch aus, wodurch der zusätzliche Traffic zu erklären ist. Schau einfach mal in den Indy's, da sollte es ne Möglichkeit geben, Redirects automatisch ausführen zu lassen, bzw. auszulesen, wohin einen der Server umleitet (Stichwort Location-Header).
Edit: In WireShark kann man sich, sofern man den Sitzungs-Key für die SSL-Verbindung hat auch den Transfer über diese Verbindung anzeigen lassen. Eine genaue Anleitung dazu hab ich aber leider nicht; hab das noch nicht zum Funzen bekommen.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Klabautermann 
Beiträge: 6366
Erhaltene Danke: 60
Windows 7, Ubuntu
Delphi 7 Prof.
|
Verfasst: Fr 27.06.08 12:58
Hi,
stimmt das habe ich vergessen zu erwähnen. Ich habe schon versucht den Indys aufzutragen, das Redirect zu behandeln, wodurch sie sich aber auf eine leere Seite umleiten lassen (RückgabeStream.length = 0 aber keine Exception), im Browser erhalte ich aber die erwartete Antwort: 0 : OK.
Somit scheinen die beiden Clients schon unterschiedlich behandelt zu werden. Es sei den dass die idHTTP nach einen Redirect keine Ergebnisse mehr entgegen nimmt. Ich werde mir das auf jeden Fall noch mal genauer bei den Indys anschauen.
// Edit: Ich habe mir einmal die Ziel Adresse des Redirects ausgeben lassen. Er will mich auf die Index-Seite des Anbieters umleiten, also auf keine API Adresse mehr sondern auf die "normale" Web Präsenz. Der leere Stream scheint also wirklich von einer unzureichenden Behandlung her zu rühren, wobei das dortige Ergebnis für mich auch Wertlos währe  .
Gruß
Klabautermann
|
|
Klabautermann
Beiträge: 6366
Erhaltene Danke: 60
Windows 7, Ubuntu
Delphi 7 Prof.
|
Verfasst: Fr 27.06.08 22:17
Hallo,
der Fehler scheint gefunden zu sein. Die Indy Komponenten senden im Header die Information:
Quelltext
dies ist nach dem Dienstebetreiber nicht korrekt, denn es müsste heißen:
Quelltext
deshalb landen meine Anfragen wohl in einem Spoofing-Filter. Da die Betreiber aber zukünftigen Partnern, die eventuell auch die Indys nutzen keine Hürden in den Weg legen wollen, wollen sie diese Klausel aus dem Filter entfernen.
Danke noch einmal für die Unterstützung.
Gruß
Klabautermann
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Fr 27.06.08 23:34
Beide Varianten sind RFC-konform. Es ist sogar falsch, wenn man eine dieser Varianten blockt.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
|
