I would have expected debug message to return:
msg.url = "...://example.com/\x3aBBB\x3aCCC";
But instead, it returns "...://example.com/:BBB:CCC", it transforms "\x3a" into ":" without way to avoid it.
Is this normal way of working? I could workaround by double slashing "https://example.com/\\x3aBBB\\x3aCCC" but will complicate whole flow enormously...
I agree on url with backslash should not be valid, however regardless of it, if I assign specific string, I wouldn't expect any transformation unless explicitly specify, don’t we?
Is it then a bug? Or any other way to workaround it?
The url with backslash works when doing a curl in linux command. I used to get taskid for proxmox api syncjob ( I can show whole command if helps)
If I replace it with colon, the proxmox api returns "parameter verification failed - 'upid': value does not match the regex pattern".
Looks like API TaskID (UPID) overcome the special characters with hex. Not only colon but also hyphen "-" is using backslash hex format "\x2d".
This is the curl command that works well though...
I was wondering the same but the return throws "JSON parse error". If I change to UTF-8, I can see that return is not the same than the one returned by CURL command. Should be \x3a and returns /x3a.
So all in all looks like the call is not done as is expected to be received by the API.
I found a way! but requires encoding the backslash itself. Double, quadruple backslashes didn't worked. I had to replace the \ highlighted ones by "%5c" (encoded backslash). Now it returns valid json parsed.