Windows API: HTTP D11 vs. D10

[himitsu]

Zitat:

Zitat von looseleaf (Beitrag 1524674)

Indy verwenden wir aus dem Grund seit Jahren nicht.

Die neueren TNetHTTPClient bzw. TNetHTTPRequest sind von Embarcadero (oder wo sie das auch immer her haben), aber jedenfalls nicht aus dem INDY-Projekt und sie sind auch Multiplatform. (leider nur HTTP, nur Client und kein Serverzeugs)

[looseleaf]

Zitat:

Zitat von himitsu (Beitrag 1524679)

Zitat:

Zitat von looseleaf (Beitrag 1524674)

Indy verwenden wir aus dem Grund seit Jahren nicht.

Die neueren TNetHTTPClient bzw. TNetHTTPRequest sind von Embarcadero (oder wo sie das auch immer her haben), aber jedenfalls nicht aus dem INDY-Projekt und sie sind auch Multiplatform. (leider nur HTTP, nur Client und kein Serverzeugs)

Danke, ich zaudere aber ein wenig, die bestehende Implementierung gegen eine andere Komponente zu ersetzen. Verwenden die den Zertifikatscache vom MSIE/Edge?

[himitsu]

Zitat:

Zitat von looseleaf (Beitrag 1524680)

Verwenden die den Zertifikatscache vom MSIE/Edge?

Ja, so weit ich das verstanden hatte.

Zitat:

Zitat von mjustin (Beitrag 1516345)

Das ist möglich, weil das Zertifikat über den Windows Zertifikatsspeicher geprüft wird.

https://www.delphipraxis.net/212095-...component.html
Wurde zumindestens von Mehreren so gesagt.

[looseleaf]

Zitat:

Zitat von Uwe Raabe (Beitrag 1524678)

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

Ich glaub, ich weiß, wo es hakt. Der Accept-HEader liefert nicht nur */*, sondern danach noch eingies an Datenmüll.

Seit jeher ist die lokale Variable

var accept: Array[0..1] of PAnsiChar;
...
accept[0]:=PAnsiChar('*/*');
accept[1]:=PAnsiChar(#0);
...
hRequest := HttpOpenRequestA(hConn, 'GET', PAnsiChar(fUrlPath+fExtraInfo), HTTP_VERSION,
nil, @accept, connFlags, 42);


ich habe das auf packed array geändert, den Rest des Codes gleich gelassen (Zuweisung, PAnsiChar, HttpOpenRequestA), et voilà, es funktioniert.

Kann mir wer erklären, warum das bisher funktioniert hat?

[himitsu]

Zitat:

Zitat von looseleaf (Beitrag 1524682)

Ich glaub, ich weiß, wo es hakt. Der Accept-HEader liefert nicht nur */*, sondern danach noch eingies an Datenmüll.

PChar haben eine #0 hinten dran und Delphi-Strings aka LongStrings (also alles außer dem ShortString) sogar zwei implizite #0#0 (so lange der Entwickler nicht am Speicher rumpfuscht, ala BufferOverflow).


Array und Packed-Array sollten hier keinen Unterschied haben, da Pointer quasi immer packed sind (weil sie keine ungerade unausgerichtete Größe besitzen, also immer bereits ausgerichtet sind und es somit auch keine Lücke gibt)




Laut Dokumentation ist die #0 aber nicht ganz richtig.

Delphi-Quellcode:

accept[0] := PAnsiChar('*/*');
accept[1] := nil;  // ein Zeiger auf NICHTS, während PChar(#0) ein Zeiger auf einen String aus einem #0 ist (eigentlich aus zwei #0, inkl. dem PChar-Terminator)

Zitat:

Code:

PCTSTR rgpszAcceptTypes[] = {_T("text/*"), NULL};

C++-NULL = Delphi-nil

[looseleaf]

Zitat:

Zitat von himitsu (Beitrag 1524683)

PChar haben eine #0 hinten dran und Delphi-Strings aka LongStrings (also alles außer dem ShortString) sogar zwei implizite #0#0 (so lange der Entwickler nicht am Speicher rumpfuscht, ala BufferOverflow).

Soweit klar, daher der Aufruf an PAnsiChar().
Ich habe im Delphi 10-Projekt auch einmal den Request auf HTTP umgebogen und erhalte immer einen sauberen Accept-Header. Keinen Datenmüll.

Kleine Beobachtung. Anscheinend war das Array immer etwas länger in D11, denn es kommen doch sehr regelmäßig Kommata im kaputten Accept-Header vor. Der Datenmüll ist auch immer derselbe, das Array hat offenbar 6 Elemente (das abschließende #0 nicht mitgezählt).

Zitat:

Zitat von himitsu (Beitrag 1524683)

Array und Packed-Array sollten hier keinen Unterschied haben, da Pointer quasi immer packed sind (weil sie keine ungerade unausgerichtete Größe besitzen, somit immer bereits ausgerichtet sind und es somit auch keine Lücke gibt)

Tja, de facto sehe ich aber einen messbaren Unterschied, der einzig und allein ander packed Deklaration hängt. Verstehen würde ich es aber sehr gerne. Irgendeine Compiler-Option dürfte da auch nicht im Spiel sein, zumindest unterscheiden sich die existierenden nicht zwischen D10 und D11.

:?:

[himitsu]

Delphi-Quellcode:

ShowMessage(SizeOf(accept).ToString);

sollte eigentlich das Gleiche liefern, egal ob

Delphi-Quellcode:

var accept: array[0..1] of PAnsiChar;

oder

Delphi-Quellcode:

var accept: packed array[0..1] of PAnsiChar;

.

Delphi-Quellcode:

accept[0] := '*/*';

Echte Konstanten (untypisierte Konstante) lassen sich auch direkt an PChar/PAnsiChar/PWideChar übergeben.

z.B. macht es keinen Unterschied, ob

Delphi-Quellcode:

ShellExecute(0, 'OPEN', ...

oder

Delphi-Quellcode:

ShellExecute(0, PChar('OPEN'), ...

.

[looseleaf]

Zitat:

Zitat von himitsu (Beitrag 1524686)

Delphi-Quellcode:

ShowMessage(SizeOf(accept).ToString);

sollte eigentlich das Gleiche liefern, egal ob

Delphi-Quellcode:

var accept: array[0..1] of PAnsiChar;

oder

Delphi-Quellcode:

var accept: packed array[0..1] of PAnsiChar;

.

Delphi-Quellcode:

accept[0] := '*/*';

Echte Konstanten (untypisierte Konstante) lassen sich auch direkt an PChar/PAnsiChar/PWideChar übergeben.

z.B. macht es keinen Unterschied, ob

Delphi-Quellcode:

ShellExecute(0, 'OPEN', ...

oder

Delphi-Quellcode:

ShellExecute(0, PChar('OPEN'), ...

.

Ja, tut es auch, immer 8. Ich verstehe absolut nicht, was hier das ursächliche Problem ist.

Danke jedenfalls für euer Feedback!

Stefan

[Delphi.Narium]

HTTP/400 Bad Request heißt einfach nur, dass das, was der Client an den Server schickt, vom Server nicht korrekt verarbeitet werden kann. "Irgendwas dadrin ist faul". Dies bezieht sich nicht nur auf die Url, sondern auf den gesamten Inhalt der Anfrage.

Zitat:

Ich glaub, ich weiß, wo es hakt. Der Accept-HEader liefert nicht nur */*, sondern danach noch eingies an Datenmüll.

Irgendwas davon irritiert den Server, deshalb seine Fehlermeldung.

Beim Aufbau des Headers muss irgendwas schieflaufen. Ein paar mögliche Ursachen wurden schon genannt. Und da das "Schieflaufen" sich bei jedem Programmstart irgendwie anders auswirkt, hast Du das Problem: Mal geht's, mal nicht, also das typische: Fehler ist nicht reproduzierbar, aber tritt regelmäßig auf.

Mögliche Ursache: Nicht sauber terminierte PChars, so dass da dann noch Teile dessen enthalten sind, was da gerade so zufällig im Arbeitsspeicher hinter dem PChar "rumliegt".

Wenn Du mal 'nen Header hier posten könntest und den vollständigen Quelltext zum Aufbau der Anfrage, wäre es eventuell möglich zu schauen, wo es da "klemmt".

[looseleaf]

Zitat:

Zitat von Delphi.Narium (Beitrag 1524732)

HTTP/400 Bad Request heißt einfach nur, dass das, was der Client an den Server schickt, vom Server nicht korrekt verarbeitet werden kann. "Irgendwas dadrin ist faul". Dies bezieht sich nicht nur auf die Url, sondern auf den gesamten Inhalt der Anfrage.

Zitat:

Ich glaub, ich weiß, wo es hakt. Der Accept-HEader liefert nicht nur */*, sondern danach noch eingies an Datenmüll.

Irgendwas davon irritiert den Server, deshalb seine Fehlermeldung.

Beim Aufbau des Headers muss irgendwas schieflaufen. Ein paar mögliche Ursachen wurden schon genannt. Und da das "Schieflaufen" sich bei jedem Programmstart irgendwie anders auswirkt, hast Du das Problem: Mal geht's, mal nicht, also das typische: Fehler ist nicht reproduzierbar, aber tritt regelmäßig auf.

Mögliche Ursache: Nicht sauber terminierte PChars, so dass da dann noch Teile dessen enthalten sind, was da gerade so zufällig im Arbeitsspeicher hinter dem PChar "rumliegt".

Wenn Du mal 'nen Header hier posten könntest und den vollständigen Quelltext zum Aufbau der Anfrage, wäre es eventuell möglich zu schauen, wo es da "klemmt".

Der Code steht 1:1 oben, es sind nur die Deklaration, die Zuweisung und das Benutzen. An amderen Stellen wird "accept" nicht verwendet.
Den Header habe ich nicht mehr, hab den Debugcode schon rausgenommen, aber es war immer derselbe Datenmüll.

Wir verwenden es jetzt mit einem packed array und sind zufrieden.