Thanks for confirming. As far as I can tell, the reason for this is that RFC3986 does not permit using an @ sign (or any of the other reserved characters that can delimit a URI) in either the username or the password. Both need to be separately percent-encoded by the scripter, and then separated by a ":" colon, before being used in the URI passed to $urlget(), in order for the URI to be parsed correctly.
In this case, it looks like mIRC needs to assume that the scripter always percent-encodes the username and password, and it should therefore always percent-decode the username and password after it has parsed the URI, before passing them to WinINET. That should resolve the issue. This change will be in the next beta.
The only possible backward-compatibility issue is if a scripter is already using username:password and one of these contains a combination of characters that looks percent-encoded. Hmm.
It may also be worth adding a percent encoding/decoding switch to the $encode()/$decode() identifiers in this case.
Note: RFC3986 indicates that using user:pass in the URI is deprecated, however since mIRC is parsing the URI independently of WinINET, it should continue to work in future.
Last edited by Khaled; 11/01/24 05:12 PM.
