Open dimabarbul opened 1 year ago
Sounds good 👍
Remark: Your use case screams for the "raw" payload mapper. Together with a header mapping configured in the target of the connection. However, this logic "use any header starting with x- and cut that off" is unfortunately not doable generically in header mapping. Only if you would already know all existing headers upfront and configure them explicity.
Summary
Live message value in JS (argument
value
inmapFromDittoProtocolMsg
function) outgoing payload mapper is sometimes base64-encoded, sometimes not. It seems to be dependent on content-type: if payload is TEXT or JSON, then payload is left intact, otherwise it's base64-encoded. There is no way for JS mapper to know it other than check content-type.Details
My use case is following: I want to allow sending any headers in the message, for example, all headers starting with "x-" (e.g., "x-my-header") should be forwarded as message headers (MQTT 5 in my setup) without "x-" prefix (e.g., "my-header"). The payload should not be changed. Messages might be sent with any content-type. AFAIK, the easiest way to do this is by using JS payload mapper.
I noticed that depending on content-type, that the message is sent with, its payload might be base64-encoded. Looks like, the logic for this is:
But in payload mapper there is simply no way to find out if the payload was encoded. No way other than checking content-type by itself. What I did to work this around is:
textPayload
fromvalue
as is, orbytePayload
asdcodeIO.ByteBuffer.fromBase64(value).toArrayBuffer()
Expected Result