Is there a urlEncode/urlDecode function that implements RFC3986

lfyey121 · 2023-07-28 09:46:36

url encoding in RFC3986 is different from urlEncode in mormot.core.buffers. Spaces cannot be replaced with +

ab · 2023-07-28 12:58:30

You are right: current UrlEncode/UrlDecode are for URI parameters, in which spaces are converted into the plus sign.
But for the main URI itself, it won't work as expected by RFC 3986.

Please try and check the new UrlEncodeName/UrlDecodeName functions:
https://github.com/synopse/mORMot2/commit/60f30baa

lfyey121 · 2023-07-29 01:59:33

Thanks for your quick response, but shouldn't the space2plus argument for calling _UrlEncode_ComputeLen in urlencodeName be 48('0')? Should it be 43('+').

lfyey121 · 2023-07-29 02:26:43

In RFC3986, should '+'(43) be converted to %43?

lfyey121 · 2023-07-29 04:07:31

RFC3986 rules will not encode ~, PHP rawUrlEncode from version 5.3 support RFC3986, the previous version will encode ~, Ali, Tencent api coding is to follow this rule.

ab · 2023-07-29 07:14:54

AFAIK '+'(43) should be converted to '%2B'.
As it is the case:
https://github.com/synopse/mORMot2/commit/4fa6b86a

About tilde ('~') this is a debate matter.
See https://blog.synopse.info/?post/2020/08 … -The-Tilde
and https://jkorpela.fi/tilde.html
The RFC should better not be followed in practice for this character.

lfyey121 · 2023-07-29 07:29:53

or You can add an argument to the urlencode(urlEncodeName) function, and it is up to the user to decide whether ~ is encoded or not

ab · 2023-07-29 07:35:14

It will be decoded anyway on the other side, so it is safe to use.

lfyey121 · 2023-07-29 07:44:01

api calls from ali,tencent, or other services will sign the encoded url. If the encoding results are inconsistent, the signature verification will fail

ab · 2023-07-29 08:43:31

Isn't the encoded URI what is transmitted, therefore signed?

lfyey121 · 2023-07-29 09:03:26

The encoded URI is transmitted, but a signature field is added, and the signature field is based on this encoded URI. The result is definitely different if the string contains ~ and %7E

ab · 2023-07-29 10:29:09

Yes, but I guess that since it is the client which makes the encoding, the signature will take it into account, because everything is done on the client side.
The result is different but still properly signed, and could properly be decoded on the server side.
I can't see how it may fail.

lfyey121 · 2023-07-29 14:09:59

Thank you. I'll test it later

lfyey121 · 2023-10-19 09:41:34

I find using TDocVariantData sortByName, and toUrlEncode can satisfy many platform API calls, if the toUrlEncode can choose encoding rules: use urlEncode or urlencodeName, so much the better

mORMot Open Source

#1 2023-07-28 09:46:36

Is there a urlEncode/urlDecode function that implements RFC3986

#2 2023-07-28 12:58:30

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#3 2023-07-29 01:59:33

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#4 2023-07-29 02:26:43

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#5 2023-07-29 04:07:31

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#6 2023-07-29 07:14:54

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#7 2023-07-29 07:29:53

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#8 2023-07-29 07:35:14

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#9 2023-07-29 07:44:01

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#10 2023-07-29 08:43:31

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#11 2023-07-29 09:03:26

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#12 2023-07-29 10:29:09

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#13 2023-07-29 14:09:59

Re: Is there a urlEncode/urlDecode function that implements RFC3986

#14 2023-10-19 09:41:34

Re: Is there a urlEncode/urlDecode function that implements RFC3986

Board footer