Windows API: HTTP D11 vs. D10

[looseleaf]

Liebe Gemeinde!

Wir siedeln gerade unsere D10 Anwendung auf D11. Wir haben eine Unit im Einsatz, die seit Jahren zuverläsig HTTP-Anfragen (vor allem HTTPS) ereldigt. Mit D11 bekommen wir immer wieder, dann aber gehäuft, die Rückmeldung HTTP/400 Bad Request. Betriebssysteme sind Windows 11, ein und dieselbe EXE funktioniert auf einem Computer, auf einem anderen nicht. Und irgendwann geht sie dann wieder.
Kopiere ich die URLs in den Webbrowser, funktioniert es immer, ich schließe daher ein Webserverproblem explizit aus.
Es sind keine URLs mit Parametern, z. B. einfach https://unserhostname/Service/serviceinfo.txt

Die verwendeten API Calls sind
InternetOpenA
InternetSetOptionA
InternetConnectA
HttpOpenRequestA
InternetQueryOptionA
InternetSetOptionA
HttpSendRequestA
InternetReadFile

Die Exception taucht beim HttpSendRequestA auf, liefert aber noch eine passende Server-Fehlermeldung. An die Serverlogs komme ich leider nicht ran.

Hat irgendjemand eine sinnvolle Idee, wo ich überhaupt anfangen soll, oder vielleicht schon einmal von so etwas gehört?

Ratlos

[Klaus01]

.. würde es helfen, wenn Du den Traffic mit wireshark tracen würdest?

Grüße
Klaus

[looseleaf]

Zitat:

Zitat von Klaus01 (Beitrag 1524667)

.. würde es helfen, wenn Du den Traffic mit wireshark tracen würdest?

Grüße
Klaus

Nicht bei HTTPS, und die fraglichen Reqeusts sind alle HTTPS. Zumindest inhaltlich (gesendete Header) hab ich keine Chance.
Aber ich ziehe gerade lokal einen Apachen hoch und werde die URLs mal dorthin umbiegen, dort bekomme ich dann wenigstens die Serverlogs.

Stefan

[himitsu]

Sollten die neueren TNetHTTPClient bzw. TNetHTTPRequest nicht auch HTTPS können? (mach es intern über Windows, bzw. auch für andere OS)

Also nicht so wie beim TIdHTTP, wo man womöglich erst noch TIdSSLIOHandlerSocketOpenSSL und eventuell paar DLLs mitbringen und anhängen muß.


Per se sollte es aber für die direkte Verwendung einer WinAPI keinen Unterschied machen, welche DelphiVersion es ist.
Und zwischen D10 und D11 sollte es auch keine großen Unterschiede geben, was z.B. die Einstellungen der PE oder des Windows-Manifests angeht, also was sich z.B. auf die Virtualisierung "alter" Programme auswirken würde (XP-Mode usw.). :gruebel:
[edit] stimmt ... ASLR ist in D11 nun aktiv

[Uwe Raabe]

Zitat:

Zitat von looseleaf (Beitrag 1524666)

ein und dieselbe EXE funktioniert auf einem Computer, auf einem anderen nicht. Und irgendwann geht sie dann wieder.

Könnte dann aber auch an ASLR liegen - das sorgt nämlich für ein verändertes Umfeld bei jedem Start. Einfach mal probeweise in den Linker-Optionen abschalten.

Sollte es damit dann funktionieren, liegt der Fehler aber nicht in dieser Einstellung, sondern im (vermutlich eigenen) Code. Das Flag macht ihn halt nur sichtbar. Ursache könnte z.B. die Verwendung von Integer sein, wo eigentlich Cardinal hingehört.

[looseleaf]

Zitat:

Zitat von himitsu (Beitrag 1524671)

Sollten die neueren TNetHTTPClient bzw. TNetHTTPRequest nicht auch HTTPS können? (mach es intern über Windows, bzw. auch für andere OS)

Also nicht so wie beim TIdHTTP, wo man womöglich erst noch TIdSSLIOHandlerSocketOpenSSL und eventuell paar DLLs mitbringen und anhängen muß.


Per se sollte es aber für die direkte Verwendung einer WinAPI keinen Unterschied machen, welche DelphiVersion es ist.
Und zwischen D10 und D11 sollte es auch keine großen Unterschiede geben, was z.B. die Einstellungen der PE oder des Windows-Manifests angeht, also was sich z.B. auf die Virtualisierung "alter" Programme auswirken würde (XP-Mode usw.). :gruebel:

Indy verwenden wir aus dem Grund seit Jahren nicht.
Was mich verwundert ist, dass es einmal geht und einmal nicht. Immer nach einem NEustart (bisher so beobachtet). Also einmal geht es zuverlässig während derselben Laufzeit, startet man neu, geht es vielleicht nicht oder schon. Aber immer bis zum Ende der Laufzeiten.

Stefan

[looseleaf]

Zitat:

Zitat von Uwe Raabe (Beitrag 1524673)

Zitat:

Zitat von looseleaf (Beitrag 1524666)

ein und dieselbe EXE funktioniert auf einem Computer, auf einem anderen nicht. Und irgendwann geht sie dann wieder.

Könnte dann aber auch an ASLR liegen - das sorgt nämlich für ein verändertes Umfeld bei jedem Start. Einfach mal probeweise in den Linker-Optionen abschalten.

Sollte es damit dann funktionieren, liegt der Fehler aber nicht in dieser Einstellung, sondern im (vermutlich eigenen) Code. Das Flag macht ihn halt nur sichtbar. Ursache könnte z.B. die Verwendung von Integer sein, wo eigentlich Cardinal hingehört.

Danke für den Hinweis, ich werde das gleich ausprobieren. Und das würde auch erklären, dass es einmal (100% der Fälle zur selben Laufzeit) geht oder nicht geht. Ich setze einfach mal das ASLR auf false. Aber verstehe ich das jetzt richtig: Es kann sein, dass es jetzt nie geht?

Stefan

[Uwe Raabe]

Das R impliziert ja eine gewisse Zufälligkeit. Dass es nie geht ist somit genauso unwahrscheinlich wie dass es immer geht. (Wenn es denn überhaupt daran liegt)

[looseleaf]

Zitat:

Zitat von Uwe Raabe (Beitrag 1524676)

Das R impliziert ja eine gewisse Zufälligkeit. Dass es nie geht ist somit genauso unwahrscheinlich wie dass es immer geht. (Wenn es denn überhaupt daran liegt)

Wenn ich es richtig verstehe, betrifft es aber immer nur das geladene Prozessimage sowie nachgeladene DLLs, die unterschiedliche zufällige Speicherbereiche zugewiesen bekommen. Wenn es aber mal läuft (und nicht dynamisch entladen oder geladen wird), dann würde alles an derselben Stelle bleiben? Insofenr verstünde ich, dass es bei einem Programmlauf geht, beim nächsten vielleicht nicht.

Andererseits weiß ich nicht, ob die Windows API für HTTP Requests dynamisch oder statisch geladen wird.

Nur zur Sicherheit: Wenn ich wirklcih einen HTTP/400 zurückbekommen, kann SSL nicht mehr das Problem sein, da ich ja schon das Backend erreiche, es würde mir also reichen, wenn ich den Request an eine HTTP-Seite umlenke und mit Wireshark nachschaue, was der Unterschied in den Headern ist, wenn es geht oder nicht geht. Valider Ansatz?

Stefan

[Uwe Raabe]

Ja, dann könnte man immerhin sehen, was am anderen Ende ankommt, und daraus weitere Schlüsse ziehen.