Nah, http-percent-encoding is a hack that doesn't work properly, let me show you an example. We'll use this helper page that echos back the parameters it receives from your request with arbitrary parameters in the URL, example:
https://echo.free.beeceptor.com/sample?message=abc&user=john&id=123
will include this in the output JSON (at the bottom)
"parsedQueryParams": {
"message": "abc",
"user": "john",
"id": "123"
}
Now let's do some test where our message to be sent will contain this string: "This is a string with whitespaces &special=characters 3 + 2 = ?" and we expect that the other end receive the exact content in the message parameter.
First attempt without special handling (like what the OP did with telegram)
{
:local messageText "This is a string with whitespaces &special=characters 3 + 2 = ?";
:local theURL "https://echo.free.beeceptor.com/sample?message=$messageText&user=john&id=123";
/tool fetch url=$theURL output=user proplist=data;
}
As expected, the request is rejected with error 400.
Now let's set http-percent-encoding=yes
{
:local messageText "This is a string with whitespaces &special=characters 3 + 2 = ?";
:local theURL "https://echo.free.beeceptor.com/sample?message=$messageText&user=john&id=123";
/tool fetch url=$theURL output=user proplist=data http-percent-encoding=yes;
}
We scroll to the right to see the end of the JSON output and... uh oh! The server received FOUR request parameters, the message parameter only contains a portion of the original message, while part of that messages became an extra special parameter. Obviously, our message could not be sent intact to the remote host!
Now the proper way, with proper URL encoding of the message text:
{
:local messageText "This is a string with whitespaces &special=characters 3 + 2 = ?";
:set messageText [:convert $messageText to=url]
:local theURL "https://echo.free.beeceptor.com/sample?message=$messageText&user=john&id=123";
/tool fetch url=$theURL output=user proplist=data;
}
The result is perfect, the server got exactly 3 parameters, with the message parameter retaining its original intended content.
Obviously we don't need to waste time finding out when we can use http-percent-encoding=yes because that is totally broken, and is a security risk!
Because if we cannot control the content of the message (for example it comes from some log entry with text value set by outside party) then additional URL parameters can be inserted by the outside party to your fetch URL parameters, something like &action=delete (like how the special parameter was inserted to the query in the example above).