Zweites AddHeader im RestRequest geht nicht

[Incocnito]

Hi Zusammen,

Zitat von hhcm:

Sicher das der Kollege recht hat

Naja, ich glaube ihm, dass sein Programm sagt "da ist nur Wert A aber nicht Wert B".
Mir scheint das aber ein Problem im Zusammenspiel zwischen Delphi und seiner
Programmiersprache zu sein. Hier im Haus hatte ich schonmal ein Problem mit .Net,
wo die Änderung eines Aufrufes von
RESTRequest.Params.AddHeader(...) nach
RESTRequest.AddParameter(...) das Problem behoben hat.
Fragt mich! Ich habe keine Ahnung was das war.
Klingt für mich nach "Oh der Kugelschreiber liegt links von der Tastatur, ja dann kann das Programm auch nicht funktionieren!".

Zitat von himitsu:

es kommt drauf an, was AddHeader macht
...

Zitat von jaenicke:

Setze einfach mal einen Haltepunkt auf TCustomRESTRequest.Execute in der Unit REST.Client. Dort wird der Request zusammengebaut.

Ich habe nun mal da reingeschaut ... war übersichtlicher als ich befürchtet hatte ...
Dort konnte ich feststellen, dass Params 2 Elemente hat und bis kurz vor dem Senden war auch alles gut.

---

Lösung:
So! Ich habe mir dann gedacht: Gut, baust du mal einen Rest-Server und schaust was da ankommt.
Das war aber auf die Schnelle nicht so einfach zu erreichen.
Ich habe zumindest nichts (jetzt heute morgen mit 15 Minuten suchen) finden können,
dafür bin ich in der Delphi-Hilfe bei meiner Suche aber auf den Rest-Debugger von Embarcadero gestoßen.
Also dachte ich mir: "Ich habe eh das Gefühl, dass ich selbst irgendwas falsch mache und
dass das normalerweise geht, sonst würden sicher schon einige Leute mit Fackel und Forke
vor dem Hauptsitz von Embarcadero rumhocken!" ... Ich habe meine Daten eingegeben und oh Wunder
genau wie in Postman geht es. Nun, im Rest-Debugger war beim Hinzufügen von Parametern ein Haken
"Nicht Verschlüsseln", den ich aktiviert hatte. Als ich den Haken entfernt hatte, bekam ich den
gleichen "401 - Unauthorized"-Fehler im Rest-Debugger, wie ich auch in meinem Programm bekommen habe.
Nach etwas Nachforscherei und habe ich dann herausgefunden, dass "AddParameter" mehrere Parameterlisten hat.
Eine Variation hat "Optionen" und hier kann man "poDoNotEncode" angeben.
Setzt komme ich weiter! Das war das Problem.

Also nochmalzusammengefasst: Bei mir lief es dann, wenn ich beide Parameter mit
RESTRequest.AddParameter('xxx', 'yyy', pkHTTPHEADER, [poDoNotEncode]); übergebe.

Das ganze hat mich dann nochmal Neugierig gemacht und ich habe mal Wireshark angeworfen,
aber egal ob mit oder ohne "poDoNotEncode", bei beidem bekomme ich bei einer https-Verbindung
nur Bytesalat, den ich selbst zumindest nicht mehr entschlüsseln kann.
Scheint also ohne den Header extra zu kodieren auch sicher zu sein.
Frage an dieser Stelle vielleicht nochmal:
Warum können Parameter seperat codiert werden? Was passiert dann?

Und mal so allgemein gefragt: Warum kommt 1 Parameter an, der 2 dann aber nicht?
Habe nur ich solch ein seltsames Verhalten?

Alles so Dinge, wo wir uns nun in Ruhe drüber unterhalten können,
da ich ja nun erstmal weiter komme.

Vielen Dank für die Tipps und Ideen soweit schonmal und ich hoffe,
dass andere in Zukunft durch diesen Post schneller auf die richtige Lösung kommen.
(Obwohl das zugegegebenermaßen doch noch unglaublich fix gelöst war!)

Liebe Grüße
Incocnito

[Uwe Raabe]

poDoNotEncode bedeutet in diesem Fall kein URI-Encoding. Das hat mit Verschlüsselung nichts zu tun, sondern damit, dass bestimmte Zeichen nicht in der URL auftauchen dürfen.

Das wird übrigens auch wirksam bei einem ContentType von APPLICATION_X_WWW_FORM_URLENCODED.

[TiGü]

Wieder so ein Fall, wo ein Blick auf die Logs von Telrik Fiddler den Unterschied zu Postman aufgezeigt und man schneller das Problem eingekreist hätte.
Diese Delphi-REST-Threads häufen sich in letzter Zeit.

Irgendwie ist die Embarcadero-Implementierung unglücklich.
Vielleicht wäre es besser gewesen keine negierende Logik zu verwenden, sondern das nicht-encodieren als Standard zu nehmen und statt eines TRESTRequestParameterOption.poDoNotEncode lieber ein TRESTRequestParameterOption.poDoEncode zu verwenden.

[Incocnito]

Zitat von Uwe Raabe:

poDoNotEncode bedeutet in diesem Fall kein URI-Encoding. Das hat mit Verschlüsselung nichts zu tun, sondern damit, dass bestimmte Zeichen nicht in der URL auftauchen dürfen.

Das wird übrigens auch wirksam bei einem ContentType von APPLICATION_X_WWW_FORM_URLENCODED.

Oh wait! Also ich hatte HTTP nun so verstanden:
1) Ich schicke einen HTTP-Befehl an eine Adresse.
Diese Adresse ist die URL.
2) Dann habe ich eine Art Umverpackung in der in Simple-ASCII mit nur den nötigsten Zeichen
beschrieben wird, was dann kommt. Der Header. Hier könnte dann auch stehen, dass der Body
in UTF-16 codiert ist. Und wann das ganze geschickt wurde. Keine Ahnung, irgendwie sowas.
3) Und am Ende habe ich dann den Body der mit irgendeiner Codierung (was halt im Header steht)
irgendeine lustige Datenmenge enthällt bei dem nur noch gegeben ist, dass die Daten als Bytes
empfangen werden können. Der Body halt. Der muss dann vom Empfänger irgendwie interpretiert werden,
was aber durch die URL (wo bin ich) und den Header (ein paar Basisinformationen) eindeutig machbar ist.

URI-Encoding war für mich das Codieren der Zeichen in der URL (und nur da), damit beispielsweise ein Leerzeichen auch ankommt, falls das Leerzeichen ein Teil der URL-Parameter ist.
Demnach müsste ich aber nur die URL-Parameter codieren (und das müsste eigendlich immer) und nicht die Header-Parameter (da macht das eigendlich nie Sinn, wenn man so denkt wie ich ... nur ASCII).

Gibt es da irgendwo Infos zu wie das genau ist? So auf die Schnelle wird
das wohl kaum einer erklären können und wollen.

---

Zitat von TiGü:

Wieder so ein Fall, wo ein Blick auf die Logs von Telrik Fiddler den Unterschied zu Postman aufgezeigt und man schneller das Problem eingekreist hätte.
Diese Delphi-REST-Threads häufen sich in letzter Zeit.

Irgendwie ist die Embarcadero-Implementierung unglücklich.
Vielleicht wäre es besser gewesen keine negierende Logik zu verwenden, sondern das nicht-encodieren als Standard zu nehmen und statt eines TRESTRequestParameterOption.poDoNotEncode lieber ein TRESTRequestParameterOption.poDoEncode zu verwenden.

Was für Logs von wem? Wie hätte man da logs aktivieren/einsehen können?
Und wie sollte man das dann mit Postman vergleichen können?
Oder fängt der wie Wireshark den Netzwerkverkehr ab und kann das bei https sogar entschlüsseln?

Ansonsten bin ich mir gerade auch nicht sicher, was der richtige Weg sein sollte.
Meiner (bisherigen!?) Meinung nach sollten die Parameter welche an die URL angehängt werden eh
ohne Außnahme codiert werden (falls das jetzt das "URI-Encode" ist und ich nicht gänzlich was durcheinander haue) und beim Rest halt nie.

Alles in Allem bin ich mehr verwirrt als vorher!

Danke schonmal für die Gedanken und die Hilfen bis hierhin!

Liebe Grüße
Incocnito

[Uwe Raabe]

Bei den Header Feldern muss man unterscheiden zwischen Standard- und Non-Standard. Standard-Header dürfen nur ASCII Zeichen enthalten oder müssen codiert werden (Deswegen ist das Default-Encoding von Embarcadero auch richtig gewählt!). Bei Non-Standard-Headern ist das nicht zwingend erforderlich - da ist das dann von der Implementation abhängig. Im Idealfall ist irgendwo angegeben, ob codiert werden muss oder nicht. Im Zweifel hilft nur ausprobieren.

[Aviator]

Zitat von Incocnito:

Was für Logs von wem? Wie hätte man da logs aktivieren/einsehen können?
Und wie sollte man das dann mit Postman vergleichen können?
Oder fängt der wie Wireshark den Netzwerkverkehr ab und kann das bei https sogar entschlüsseln?

Schau dir mal Fiddler an. Ich habe damit auch noch nicht so viel gearbeitet und bin nicht so firm drin, aber der hat schon ein paar coole Features.

Die Funktion die du benötigt hättest wäre, dass er den HTTPS Stream lesbar macht. Damit das funktioniert, hängt sich Fiddler auf Port 443 ins System rein und gaukelt ein Zertifikat vor, dem dein System vertrauen muss (wird alles automatisch eingerichtet). Dadurch, dass Fiddler dann als HTTPS Endpunkt fungiert, sind die Daten dort ja wieder entschlüssel und dadurch lesbar. Im Nachgang werden die wieder verschlüsselt und wieder als HTTPS Stream an den eigentlichen Server gesendet. Das Gleiche passiert mit der Antwort auf dem Rückweg.

Das mal so als einfache Erklärung und ohne Gewähr auf Vollständigkeit und Richtigkeit.