SOAP: XE3-Client liefert Daten, XE8-Client liefert Fehler

[kretabiker]

Hallo,

ich habe ein seltsames Phänomen, an dem ich gerade hänge.

Gegeben ist ein in PHP geschriebener SOAP-Webservice. In meiner Applikation frage ich diesen Webservice mit Hilfe der THTTPRIO-Komponente ab. Unter XE3 funktioniert das problemlos, sowohl auf meinem eigenen Rechner als auch in einer RemoteDesktop-Umgebung.

Jetzt habe ich dieses Projekt nach XE8UPD1 umgestellt. Starte ich die Abfrage auf meinem lokalen Rechner, funktioniert sie einwandfrei, führe ich die Abfrage in unserer RemoteDesktop-Umgebung (WinServer 2003 R2) aus, kommt es zu einer Fehlermeldung, die sinngemäß besagt "Das System kann die angegebene Datei nicht finden" mit Errorcode 2. Durch Statusmeldungen habe ich herausgefunden, dass der Event THTTPRIO.HTTPWEBNODE.ONPOSTINGDATA noch abgefeuert wird, bevor dann im Event THTTPRIO.HTTPWEBNODE.ONWININETERROR der ErrorCode 2 angezeigt wird.

Ich habe schon versucht, durch Tracen auf meinem Entwicklungsrechner die Ursache einzukreisen, komme aber nicht dahinter, was den Fehler erzeugt. Leider habe ich auf dem Terminalserver keine Entwicklungsumgebung (und auch sonst dort nur eingeschränkte Testmöglichkeiten). Firewall und Virenscanner hatte ich schon deaktiviert.

Wie gesagt, die XE3 geschriebene Version arbeitet problemlos, nur die XE8-Version schmeißt den Fehler aus, und auch nur in der RemoteDesktop-Umgebung.

Hat jemand eine Idee, woran so etwas liegen kann?

[mkinzler]

Könnte ja auch an der veralteten Systemumgebung liegen

[kretabiker]

daran habe ich auch schon gedacht, aber da habe ich leider keinen Einfluß drauf, ist ein Kundenrechner. Wäre fatal, wenn ich deswegen nicht auf XE8 umsteigen könnte.

[kretabiker]

Mist, es scheint tatsächlich am veralteten Windows zu liegen. Ich habe mal auf anderen Kundenservern mit neuerem Windows Server-OS getestet, da läuft auch, die XE8-Version.

Zeit, ne Mail an den Kunden zu schreiben.

Falls noch jemand eine andere Idee hat, her damit.

[Sherlock]

Es ist immer gut, wann man nicht selbst Schuld ist. Wozu noch weiter suchen?

Sherlock

[kretabiker]

Oh, ich würde sehr gerne die Ursache dafür finden und beseitigen, habe aber keinerlei Idee mehr, wo ich suchen oder allein mit meiner Suche ansetzen soll, es tritt ja nur auf diesem einen Rechner auf bisher.

Einen Testclient, den ich inzwischen aufgesetzt habe, verhält sich genauso. Ich habe auch schon die Delphi-Sourcen von SOAPHTTPTRANS.pas verglichen, weiß aber eben nicht, welche der dort erkennbaren Änderungen zu dem genannten Fehler führen.

Falls du noch eine Idee hast, bitte her damit.

[TiGü]

Und dein Programm, welches mit XE3 gebaut wurde, kann sich problemlos mit dem WinServer 2003 R2 verbinden?

[kretabiker]

@TiGü: Nicht ganz richtig: Das Programm läuft auf dem Windows 2003 R2 Server auf einem RemoteDesktop. Der Webservice liegt ganz woanders. Und ja, das XE3-Kompilat kann von überall problemlos mit dem Webservice kommunizieren (also auch von dem Win2003-Server), das gleiche Programm mit XE8 compiliert funktiert nicht richtig von dem RemoteDesktop auf dem Win2003-Server. Von meinem eigenen Rechner und von anderen RemoteDesktop-Servern funktioniert auch das XE8-Kompilat einwandfrei.

[TiGü]

Und konntest du auch die genaue Stelle in Soap.SOAPHTTPClient.THTTPRIO in der XE8 Version identifizieren, die den Fehler auftreten lässt und hast du diese Stelle mit den XE3 Quelltexten verglichen?
Da muss sich doch etwas entscheidenes zwischen den Versionen geändert haben.

[kretabiker]

Die fehlerhafte Stelle kann ich eben nicht identifizeren: Auf meinem Entwicklungsrecher funktioniert alles und auf dem Terminalserver habe ich keine IDE (und darf ich auch nicht installieren). Die Änderungen in der PAS-Datei zwischen XE3 und XE8 sind deutlich sichtbar im Diff, aber ich weiß nicht, wo genau es knallt - das macht mich ja so ratlos.

[mkinzler]

Eine vollständige IDE ist nicht unbedingt notwendig, es reicht ja der Remote Debugger. U.U. könntest Du Dir auch einen Testrecher aufsetzen.

[Bernhard Geyer]

Ich Tipp mal auf den MS XML-Parser der in neuerer Version erwartet wird aber in dieser W2k3-Installation zu alt ist.

[mquadrat]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1306483)

Ich Tipp mal auf den MS XML-Parser der in neuerer Version erwartet wird aber in dieser W2k3-Installation zu alt ist.

Klingt auf jeden Fall plausibel

[kretabiker]

Guten Morgen allerseits,

danke für die Ratschläge zu diesem Problem.

1. Remote Debugger: Daran habe ich nicht gedacht, da noch nie benutzt. Ein kurzer Blick in die Doku, das sollte auch auf dem Kundenserver möglich sein. Ich kläre das mit dem Kunden und werde es dann damit versuchen.
2. W2k3-Testumgebung: Daran habe ich gedacht. Derzeit sucht mein Systemlieferant eine VM, auf der ich testen kann. Das wird parallel zu 1. passieren.

[kretabiker]

Update von dieser Front:

- Der Fehler tritt auch auf einem anderen Win2k3R2-Server auf, den ich für Testzwecke nutzen konnte. Auf allen anderen getesteten Systemen (Win7, Win8, W2k8, W2k12) läuft es.
- Der Versuch, die Fehlerursache per Remote Debugger einzukreisen, ist gescheitert. Zwar gelang es mir im lokalen Netz, ein Verbindung aufzubauen und zu debuggen, aber da waren beide Systeme Win7. Der Versuch, mein Programm auf den in fremden Netzen befindlichen W2K3-Rechnern anzusprechen, gelang nur teilweise: Zwar konnte ich mich mit den jeweiligen Prozessen verbinden, aber die von mir gesetzten User-Breakpoints wurden nicht erkannt, debuggen war daher nicht möglich. Vielleicht habe ich was falsch gemacht? Ich meine aber auch gelesen zu haben, dass das RD nur innerhalb eines Netzes funktioniert. Firewalls wurden - sofern vorhanden - für die Tests kurzfristig abgeschaltet.

Ich habe mal unsere Kundenliste gecheckt: Wir haben tatsächlich nur einen Kunden mit W2k3 im Einsatz - nämlich den, bei dem der Fehler aufgetreten ist. Dem Kunden ist das Problem des End-Of-Life seines Systems auch bewußt und er strebt einen kurzfristigen Umzug auf einen neuen Rechner mit dann aktuellem Windows Server OS Windows Server 2012. Trotzdem bleibt ein ungutes Gefühl, die Ursache nicht wirklich zu kennen.

[Bernhard Geyer]

Compiliere die exe doch mit maximalen Debug-Infos (Debug-DCU) und lass dir mit JCLDebug-Units (oder auch mit Madexpert oder ähnlichen) den vollständigen Aufrufstack geben

[kretabiker]

So, vorläufige Abschlussmeldung zu diesem Thema: Nach ausführlichen Tests mit PAServer konnte ich das Problem auf einen Aufruf der WinInet-Funktion HttpSendRequest (bzw. auf eine Fehlerprüfung im Umfeld davon) in der Unit SOAP.SOAPHTTPTrans.pas einkreisen. Dieser Aufruf erfolgt in XE8 nach dem Muster

Delphi-Quellcode:

{$IFDEF UNICODE}
          HttpSendRequest(Request, nil, 0,
                          DatStr.Bytes, DatStr.Size);
{$ELSE}
          HttpSendRequest(Request, nil, 0,
                          @DatStr.DataString[1],
                          Length(DatStr.DataString));
{$ENDIF}
          
          RetVal := HandleWinInetError(GetLastError, Request, True);

d.h. der Aufruf der Funktion HandleWinInetError erfolgt immer unabhängig vom Ergebnis der HttpSendRequest-Funktion, welche entweder True oder False liefern kann.

In XE3 sieht das noch ein wenig anders aus:

Delphi-Quellcode:

{$IFDEF UNICODE}
          WinInetResult := HttpSendRequest(Request, nil, 0,
                          DatStr.Bytes, DatStr.Size);
{$ELSE}
          WinInetResult := HttpSendRequest(Request, nil, 0,
                          @DatStr.DataString[1],
                          Length(DatStr.DataString));
{$ENDIF}
          if not WinInetResult then
            RetVal := HandleWinInetErrorEx(GetLastError, Request, True);

Hier erfolgt der Aufruf von HandleWinInetError nur, wenn das Ergebnis von HttpSendRequest False ist, was meines Erachtens richtig ist.

Ändere ich den Sourcecode in XE8 so, dass der Aufruf an dieser Stelle wie bei XE3 erfolgt, funktioniert die Webservice-Abfrage auch unter W2k3R2 einwandfrei; es war wohl reine Glücks- bzw. Pechsache, dass es auf meinem Entwicklungsrechner und unter Win7 funktioniert, nicht jedoch auf W2k3R2-Maschinen, woher dort der Errorcode 2 auch immer kommt. Ich denke, das ist ein Bug in XE8, jedenfalls habe ich das so an den Embarcadero-Support gemeldet. Wer es gerne in seinem eigenen Source mal nachschauen möchte: Soap.SOAPHttpTrans.pas, class THTTPReqRes, function Send, Zeile 1156ff. Der (meines Erachtens) fehlerhafte Aufruf von HandleWinInetError erfolgt aber noch an zwei weiteren Stellen innerhalb der Unit.

Wenn sich der Emba-Support meldet, gibt es noch ne abschließende Abschlußmeldung.

[kretabiker]

Vom Emba-Support: Wurde als Bug anerkannt. "Reported internally as RS-64962"