Bug 503748

Summary: KUriFilter unexpectedly encodes some special characters of remote URL with a query containing two @
Product: [Frameworks and Libraries] frameworks-kio Reporter: Stefano Crocco <stefano.crocco>
Component: generalAssignee: KIO Bugs <kio-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: john.kizer, kdelibs-bugs-null
Priority: NOR    
Version First Reported In: 6.13.0   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Stefano Crocco 2025-05-04 11:52:32 UTC
If I call KUriFilter::filterUrl with an URL with a query containing two @ symbols, some of the special characters are encoded, which changes the URL. For example:

https://abc.com/?mail1=mail@xyz.com&mail2=othermail@abc.org
is filtered into
https://abc.com/%3Fmail1%3Dmail%40xyz.com%26mail2%3Dothermail@abc.org

I don't think that this should happen, as the original URL is valid.

I don't know whether this is a new behavior or not: I started noticing it a couple of months ago using Konqueror to open a link to a message in Google Classroom. I got the link in a mail sent automatically by Google Classroom, so I assume it's correct (and indeed it works in other browsers). However, after clicking on it I was shown a page claiming the URL didn't exist. I then tried copying the URL from the mail and pasting it in Konqueror location bar. After pressing return, I noticed that the URL in the location bar had been changed, with several special symbols (?, =, one of the two @) being replaced by their percent encoding representation. For example, the URL

https://accounts.google.com/AccountChooser?continue=https://classroom.google.com/s?email%3Duser.name@my.company.it&Email=user.name@mycompany.com
had become
https://accounts.google.com/AccountChooser%3Fcontinue%3Dhttps://classroom.google.com/s%3Femail%253Duser.name%40my.company.it%26Email%3Duser.name@mycompany.com
Comment 1 John Kizer 2025-05-09 04:07:29 UTC
Hi - merging this in with what appears to be the same underlying issue, thanks!

*** This bug has been marked as a duplicate of bug 449227 ***