D11: SOAP (HttpClient.Win, SendData) liefert 12152 Fehler beim Senden der Daten: Der

[looseleaf]

Liebe Gemeinde!

Wir verwenden SOAP Requests in unserem Programm, dei auch grundsätzlich funktionieren. Aber einer, bei dem auch ein Attachment dran ist, das etwas größer ist, macht uns Sorgen. Hier steigt Delphi in System.Net.HttpClient.Win an der Stelle aus, wo die Daten an den Server geschickt werden. Nach etwa 100kB Daten (von ertwa 400kB) ist es mit
"Fehler beim Senden der Daten: (12152) Der Server lieferte eine ungültige oder unbekannte Rückmeldung"
vorbei.

Ich habe gesehen, dass die Implementierung dieser Komponenten im Vergleich zu Delphi 10.2 komplett überarbeitet wurde.

Pervers ist, dass es funktioniert, wenn ein Haltepunkt an der Stelle, wo ein

// Send Request
if not WinHttpSendRequest(LRequest.FWRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0, WINHTTP_NO_REQUEST_DATA, 0, LDataLength, 0) then
Exit(HandleExecuteError(@SNetHttpClientSendError, ARequest));

gemacht wir und ich dort so in etwa 5 Sekunden warte.

Es gibt keine parallelen Requests, die hier aus irgendwelchen Threads dazwischenfunken könnten.

Ich bin schon wieder mal ratlos. Ich könnte natürlich den kompletten System.Net.HttpClient.* Code aus Delphi 10.2 verwenden...ODer zumindest die DoExecuteRequest Methode. Aber gefallen tut mir das nicht :/

Stefan

Stefan

[jaenicke]

Hast du die Timeouts schon angepasst?

[looseleaf]

Zitat von jaenicke:

Hast du die Timeouts schon angepasst?

Die setzen wir am RIO.Objekt programmtechnisch seit jeher auf 300*1000 also 5 Minuten.

Außerdem wäre es umgekehrt zu erwarten: Wenn ich länger warte, steigt das Framework aus. Aber es ist ja so, dass es aussteigt, wenn ich *nicht* mit einem Haltepunkt warte. :/

[himitsu]

Das Senden und Empfangen wird öfters in einem anderen Thread erledigt.
Somit kann es auch ein Synchonisierungs-/Paralleliserungsproblemchen sein ... multithreaded auf etwas, was ihr z.B. vorzeitig wieder freigebt/überschreibt.

[looseleaf]

Zitat von himitsu:

Das Senden und Empfangen wird öfters in einem anderen Thread erledigt.
Somit kann es auch ein Synchonisierungs-/Paralleliserungsproblemchen sein ... multithreaded auf etwas, was ihr z.B. vorzeitig wieder freigebt/überschreibt.

Hm, wir haben eine zweite, komplett getrennte RESTRequest-Komponente in einem anderen Form, die über einen Thread Anfragen schickt.

Ich habe den Thread einmal komplett deaktiviert, er tut nichts mehr. Kein Effekt.

Was mir aber auffällt: Wir haben auch noch 2 andere Requests vor dem eigentlichen "bösen", bei dem wir das Backend abfragen, ob die Funktion momentan überhaupt ausgeführt werden darf. Hier sind keine Threads im Spiel, sondern die Abfragen passieren hintereinander. Lasse ich beide weg, funktioniert der "böse" Request. Jetzt wird's spannend.

[looseleaf]

Weitere Information: Ich habe ein Wireshar-Protokoll gemacht. Da es sich um einen HTTPS-Strom handelt, sehe ich leider nicht viel. Was ich aber sehe, ist dass wir mittem im Strom ein FIN, ACK an den Server schicken, der das dann etwas später mit einem RST,ACK quittiert und den Port schließt.

Bleibt also die Frage: Wer schickt mir ein FIN, ACK und warum.

[himitsu]

Wenn du diesen Netzwerkverkehr im Sysinternals ProcessMonitor siehst,
dann kannst du dort eventuell auch den Stacktrace zu dieser Aktion dir anzeigen lassen.

[Klaus01]

Zitat von looseleaf:

Weitere Information: Ich habe ein Wireshar-Protokoll gemacht. Da es sich um einen HTTPS-Strom handelt, sehe ich leider nicht viel. Was ich aber sehe, ist dass wir mittem im Strom ein FIN, ACK an den Server schicken, der das dann etwas später mit einem RST,ACK quittiert und den Port schließt.
Bleibt also die Frage: Wer schickt mir ein FIN, ACK und warum.

Wenn Du Zugriff auf die keys hast, die kannst Du in Wireshark einlesen und so dann auch den Traffic dekodieren.

Was eventuell noch hilfreich sein kann Fiddler Classis

Grüße
Klaus

[looseleaf]

Das Problem im konkreten Fall scheint gewesen zu sein, dass die Keep-Alive-Pakete das ganze umbringen.

Ich habe mir System.Net.HttpClient.Win.pas in mein Projekt geholt und dort bei den anderen WinHttpSetOption() Aufrufen noch

LOptionValue := WINHTTP_DISABLE_KEEP_ALIVE;
WinHttpSetOption(LRequest.FWRequest, WINHTTP_OPTION_DISABLE_FEATURE, @LOptionValue, sizeof(LOptionValue));

ergänzt. Jetzt funktinoiert es.

Interessant ist, dass im Delphi 10.2 Code das KEEP_ALIVE Flag auch nicht explizit deaktiviert ist, es aber offenbar funktioniert.

Danke für euer Feedback!

Stefan