Encoding von Headervariablen in DataSnap

[Maliko]

Moin,

bei uns läuft eine API welche auf DataSnap basiert und leider ist dabei jetzt aufgefallen, dass diese ein Problem mit Umlauten hat. Wenn ich im Header des Requests einen Umlaut mitschicke, kommt dieser kaputt in der Schnittstelle an (wird als Fragezeichen angezeigt).

Hier ein Beispielaufruf (zur Einfachheit in Curl)

Code:

curl --request GET \
  --url https://localhost:1234/api/rest/v21/Ping \
  --header 'Authorization: Basic 125jkhlkjsdhflsjdhflskjhfd==' \
  --header 'x-api-key: xxxx-xxxx-xxxx-xxxx-xxxx' \
  --header 'x-environment: Test' \
  --header 'x-vendorid: äbc-abc-abc'

Das ä kommt dann kaputt beim Server an. Auf die Variable greif ich mit folgendem Code zu:

Code:

Request.GetFieldByName('X-Vendorid')

Hat jemand eine Idee woran das liegen kann und wie ich den Encodingfehler behebe? Im Internet hab ich dazu nämlich nix gefunden (oder ich bin mal wieder zu dumm zum suchen).

[DeddyH]

https://stackoverflow.com/questions/...-a-http-header Du solltest Dich auf ASCII beschränken. Sollte das wieso auch immer nicht möglich sein, könntest Du den fraglichen Header BASE64-kodieren und auf Serverseite wieder dekodieren. Schön ist aber anders.

[Maliko]

Jup das hat ein Kollege auch gerade herausgefunden. Wir haben uns für den einfacheren Weg entschieden und haben in der API-Doku angegeben, dass der Wert keine Sonderzeichen/Umlaute außer '-' beinhalten darf. Danke dir trotzdem.

[Rollo62]

Zitat von Maliko:

... dass der Wert keine Sonderzeichen/Umlaute außer '-' beinhalten darf. Danke dir trotzdem.

Ist das nicht sowieso Pflicht bei digitalen Schnittstellen?
Ich weiss nicht wieviele Stunden ich schon nach Fehlern gesucht habe, wo einfach irgendwelche UTF8 Zeichen oder chinesische Zeichen verwendet wurden, die man auf den ersten Blick gar nicht so einfach erkennen kann.

Mittlerweile gebe ich bei "-" auch immer den ASCII HEX-Code mit an, damit mir keiner einen "Gedankenstrich" unterjubelt, wie das gerne von Leuten aus dem Grafikdesign gemacht wird.