Bug or normal behaviour with auto replace "\x3a" code to :?

General
1

Hello community,

I am facing some unexpected behaviour when assigning string to msg.url and debugging the value. Function as follow:

imagen
imagen1264×308 16.3 KB

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

Is this normal way of working? I could workaround by double slashing "https://example.com/\\x3aBBB\\x3aCCC" but will complicate whole flow enormously...

Thank you,

2

I didn't think that https://example.com/\x3a... was a valid url. I thought backslash was not allowed.

3

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)

4

In a javascript string "\x3a" means hex 3a, which is a colon. I don't know of a way to stop that other than using double backslash.

Interestingly, using encodeURI on your uri leaves it as a colon. Have you checked whether the url with a colon works?

5

Could be that the transformation in only in the debug display but the string itself has the value your function gave…

Pierre RUWET

6

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

imagen
imagen810×146 6.02 KB

7

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.

8

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.