There appears to be some kind of attempt at normalizing or rebuilding a protocol handler URL causing the URL to be altered before it is passed to the handler. The specific case I encountered this is with the game Vintage Story. It allows installing mods through such a handler. An example URL it would pass is: vintagestorymodinstall://vsimgui@1.1.7 Running kioclient exec 'vintagestorymodinstall://vsimgui@1.1.7' results in the following URL being passed to the application: vintagestorymodinstall://vsimgui@1.1.0.7 This looks to me like it's trying to parse the URL and treating it as a username and an IP address. My understanding is that it is the role of the handler to interpret the contents of the URL and it should be passed unchanged. In this case these components represent a mod name and a version number. I tried to track this down but got lost somewhere in between openurljob.cpp and applicationlauncherjob.cpp.
Very strange. I can reproduce it.
This actually happens right when the QUrl gets created. https://invent.kde.org/qt/qt/qtbase/-/blob/1da7558bfd7626bcc40a214a90ae5027f32f6c7f/src/corelib/io/qurl.cpp?page=2#L1141 Intentional behavior in Qt. Though arguably we should be able to opt out of this. At the same time one has to wonder if we want to because posix conforming command line tools all behave like this and we do run mutations on the input anyway because we also accept local file paths and what not. ❯ ping 1.1.0 PING 1.1.0 (1.1.0.0) 56(84) bytes of data. In any event, best file an upstream bug about this.
I've reported this to the Vintage Story devs as I don't think Qt is doing anything wrong here. For anyone wishing to follow this, the report is here: https://github.com/anegostudios/VintageStory-Issues/issues/5312