Windows API: HTTP D11 vs. D10

[looseleaf]

Zitat von 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)

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.

[looseleaf]

Zitat von Uwe Raabe:

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 von looseleaf:

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 von himitsu:

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 von himitsu:

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]

ShowMessage(SizeOf(accept).ToString); sollte eigentlich das Gleiche liefern, egal ob var accept: array[0..1] of PAnsiChar; oder var accept: packed array[0..1] of PAnsiChar; .


accept[0] := '*/*';
Echte Konstanten (untypisierte Konstante) lassen sich auch direkt an PChar/PAnsiChar/PWideChar übergeben.

z.B. macht es keinen Unterschied, ob ShellExecute(0, 'OPEN', ... oder ShellExecute(0, PChar('OPEN'), ... .

[looseleaf]

Zitat von himitsu:

ShowMessage(SizeOf(accept).ToString); sollte eigentlich das Gleiche liefern, egal ob var accept: array[0..1] of PAnsiChar; oder var accept: packed array[0..1] of PAnsiChar; .


accept[0] := '*/*';
Echte Konstanten (untypisierte Konstante) lassen sich auch direkt an PChar/PAnsiChar/PWideChar übergeben.

z.B. macht es keinen Unterschied, ob ShellExecute(0, 'OPEN', ... oder 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