Zweites AddHeader im RestRequest geht nicht

[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.