Simple but serious bug caused by QUrl behavior in kde-open, when url contains a plus sign

[ShwStone]

I'm currently investigating a bug in kde-open related to its inability to correctly parse certain custom URL protocols that contain a special character.

The Scenario:

When opening a remote file via the vscode-remote protocol, xdg-open receives a URL similar to this:
vscode-remote://ssh+devserver/my/file/path
(Where ssh+ is an integral part of the scheme identifier.)

As a backend for xdg-open, kde-open uses QUrl::fromUserInput to convert the input string into a QUrl object. It then uses the resulting scheme (from .scheme()) to look up a registered x-scheme-handler and select the appropriate application.

The Core Problem:

When the input string's scheme contains a plus sign (+), QUrl::fromUserInput automatically prepends http:// to the link. This forces the URL to be interpreted under the http protocol, which prevents kde-open from finding the correct program and ultimately causes a browser to be launched.

My analysis of the documentation and source code suggests that URLs containing a + sign (or its escape, %2B) are considered invalid by Qt's initial parsing logic, triggering QUrl::fromUserInput's "best guess" mechanism, incorrectly defaults to prepending http://.

Questions for Discussion and Clarification:

1. URL Standard Compliance: Why is a URL scheme containing a plus sign considered invalid? Is this mandated by RFCs (URL standards)? If not, is this limitation in Qt necessary, or should it be revisited?
2. Guessing Conservatism: Is it possible to make the QUrl::fromUserInput guessing logic more conservative, ideally preserving the original scheme if it's not a known standard protocol like ftp://?
3. KDE Architectural Choice: If a change cannot be made at the Qt level, should KDE reconsider using QUrl::fromUserInput for accepting general URL input in utilities like kde-open? (A similar concern is already documented in KDE Bug 501398.)

I am not affiliated with the KDE or Qt development teams, but I am keen to contribute to the resolution of this bug. I'm seeking insight into the underlying standards and the most appropriate path forward.

[ShwStone]

code to reproduce: https://pastebin.com/rTuaeK02

[IgKh]

@ShwStone Welcome to the forum.

This topic doesn't really fit here as it not really a Qt usage question - Qt is more of an incidental implementation detail of a KDE user tool. I don't believe there are many KDE developers lurking here, and even so it is not the natural place for discussion of that nature.

Issues should be reported to KDE's bugzilla, but I understand that it is hard to get tickets noticed there. Perhaps KDE's user forum (https://discuss.kde.org/) have a better for that, or the kde-devel mailing list.