Bug 439690 - kde-open5 doesn't respect xdg scheme handler when url contain equals character
Summary: kde-open5 doesn't respect xdg scheme handler when url contain equals character
Alias: None
Product: kde-cli-tools
Classification: Unclassified
Component: general (show other bugs)
Version: 5.22.3
Platform: Archlinux Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Aleix Pol
Depends on:
Reported: 2021-07-09 17:53 UTC by top.plan0862
Modified: 2022-02-02 10:20 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description top.plan0862 2021-07-09 17:53:16 UTC
With a custom x-scheme-handler set in XDG, when the URL contain '=', link is always opened in default browser instead of link handler application.

1. Install an application which adds a desktop file with a MimeType=x-scheme-handler/custom-handler.
2. Execute 'xdg-open custom-handler://key=value' (xdg-open is a script which actually passes the call to kde-open5 in KDE)

Link opens in default browser.

Link should be opened by application set to handle the custom scheme. With the "=" character removed from the link, the application opens as expected.

Linux/KDE Plasma: Arch Linux 5.12.14, fully up-to-date 
KDE Plasma Version: 5.22.3
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2


Details below are specific to my application, but bug seems to manifest for any custom handler when the link contains = character. For example you could try msteams://test vs msteams://te=st if you have MS Teams installed.

Install EObcanka (Czech national ID card client application from AUR (or deb is available here https://info.eidentita.cz/Download/). This creates /usr/share/applications/eopauthapp.desktop with contents:

[Desktop Entry]
Name=eObčanka Identifikace
Comment=Elektronická identifikace občanským průkazem
Exec=/opt/eObcanka/Identifikace/eopauthapp.sh %u

Ensure that 'xdg-mime query default x-scheme-handler/czeeopauth' returns eopauthapp.desktop.

Then try 'xdg-open czeeopauth://mwid=1'. Opens in default browser.
Compare with 'xdg-open czeeopauth://mwid1' (without the =). Opens cor using eopauthapp client application.
Comment 1 Aleix Pol 2021-07-09 23:40:15 UTC
= is a reserved character in URL spec:

%3d instead should work
Comment 2 top.plan0862 2021-07-10 09:09:03 UTC
I see your point. Unfortunately I am not the author of the problematic application, merely a user. The application is the client of the Czech national ID authority for citizens to authorise themselves when using eGovernment services. I will try to inform them. However we're talking public sector here, I'm not holding my breath (though they may surprise).

However, I would also opine that with a custom scheme handler application, it should be up to the client application itself to determine the validity of the URI after the scheme:// part. Yes, this application doesn't conform to the RFC, but an alternative viewpoint is the kde-open/kioclient shouldn't care after it has determined that the (invalid) URI is handled by a special application. Just pass the URI to the application and let that worry about it. 

For information, this problem makes the Czech eGovernment application unusable for Chromium based browsers (i.e. all the main ones except Firefox) which use xdg-open to handle custom schemes. Workaround is to use Firefox of course (which uses it's own built is custom scheme handling which works fine despite the invalid URI) or hack xdg-open to call its open_generic function (also works fine) instead of open_kde when it recognises we're in KDE. Neither workaround is very satisfactory.
Comment 3 Lubos Dolezel 2021-12-01 10:59:43 UTC
I just came here to report the same issue. It gets even funnier than that:

czeeopauth://mwid=767aae75 -> kde-open5 changes scheme to http and passes it back to the browser (BAD)
czeeopauth:/mwid=767aae75 -> correct app launched
czeeopauth://mwid767aae75 -> correct app launched
czeeopauth:mwid=767aae75 -> correct app launched

Please note that using %3d instead of the = sign does NOT fix the problem.

kde-open5 turns the original URL into something like "http://czeeopauth/mwid=767aae75". I seriously don't think that's a behavior defined by the RFC. This is definitely a bug (still present in 5.23.4).