Entering URL as "Link to Location (URL)" failure

I want to enter a URL in the “Create New | Link to Location (URL)” dialog box. The URL I enter has the form of:


If I enter this name in the “Enter Link to Location (URL):” part of the dialog OS 13.2 accepts it but changes it by dropping all “%nn” parts of the name and substituting underscores for them. Naturally this does not work. How can i get OS 13.2 to accept the name of the URL as it is, which does work as a valid URL link ?

I may be a not completely awakened, but I fail to understand what/where you have that “Create New | Link to Location (URL)” dialog box. It being a dialog box, I assume that it is in a GUI interface. I also fail to see where you stated what desktop you are using.

In short I have no idea what you are doing. And that makes helping a bit difficult :slight_smile:

I am using KDE in OS 13.2. I right-click within a folder, get the Context Menu, click “Create New” and then “Link to Location (URL)…” and a diialog box comes up. The rest is explained in my OP.

I assume you mean with “click in a folder” that you do this in Dolphin. Because that is where I found the contextt menue you mention.

When I try to re-create what you do (using the file name tttt and the URL you use), I get a file tttt with contents:

henk@boven:~> cat tttt
[Desktop Entry]

The above shows that the %nn phrases are replaced by the characters they represent (& and +). Not by _ as you say.

As “something” is not realy a good Fully Qualified Domain Name, it is a bit difficult to test this further. As my impression is that you have some real problem, why then do you not post a real URL that fails?

The URL which fails is:


After creating the desktop entry through the GUI actons I mentioned in my OP, I open the file itself in my editor and I see:

[Desktop Entry]

As you can see the URL in the file is changed from:




Needless to say the entry in the desktop entry file does not work.

The modified URL works.
The changes you’re describing are fairly common, it’s URL encoding for special symbols. This is done because the original characters being substituted can have special meaning and functionality in their original form… and may even be filtered/blocked for that reason.

By using URL encoding, the string of characters becomes indisputably text, unable to invoke special functionality.

So, if the URL does not work for you, it is for some other reason than the substituted escape characters

The following is one of many references on the Internet that lists these special characters when used in HTML code and URLs

BTW - since an entire HTML page can be similarly encoded, it’s a simple way to obfuscate a web page although of course the method is so well known the code can easily be decoded (and would have to be for web browsers to read and render the code).


That is the human way of saying it (“it does not work” is a infamous way of describing nothing), but I guess I can understand the technical meaning of it

I repeated your way of doing and indeed, when I click on it, Firefox is started, the website shows a page, but it is an error page beacuse the page needed can not be found.

The problem being either:

  • the URL encoding should not have been translated by Dolphin on creation of the file;
  • the mecahnism (in Dolphin? in any case in KDE) should have translated (back) the URL to URL encoing on execution.

I am not sure which one is the case, But a Bug report seems logical to me.

You can file that at openSUSE:Submitting bug reports - openSUSE Wiki (the same username/password as here). Please explain the technical facts as good as possible and use your example so people can easily replay the case.

That’s pretty interesting.

I think the problem is a bug both in KDE… Yes, typically the function should not decode the URL encoding…
But, I also would think that this is also Oracle’s error. Normally the webserver should accept both encoded and decoded characters.

So, this is probably a very rare instance when 2 somewhat rare configuration errors have conspired to create your failure.

BTW - I verified that if you open up the properties of your HTML shortcut and re-enter your original working URL and click “OK” the shortcut works.


As those characters (& and +) have a special meaning inside an URL and thus must be escaped (http://www.ietf.org/rfc/rfc3986.txt), I can not see why Oracle is to be blamed…

When you mean by this rather intricate sentence that you changed the URL in the file to a correct one and that it then worked, I can confirm that.

henk@boven:~/test/urlmetraar> cat link
[Desktop Entry]

When I “click on it” in Dolphin, Firefox opens and the correct page is loaded.

Thus IMHO from the two possibilities I offered above, we can now say that the first one is the one that bothers us. Dolphin should store the entered URL as it is, but for some reason it thinks tthat is has to be clever and translate it. Which we think is wrong.

As part of a properly constructed webserver,
I assume that any URL would be configured to always treat the URL as pure text, else it’d possibly be the most elementary way to inject code.

Coding-wise, this is not difficult, it just has to be done.

This is why it should be possible to use a variety of characters safely in a string and not accidentally or maliciously invoke functionality. Typically when I see special characters in a string, they are delimiters sometimes with special meaning to invoke web code but you shouldn’t be able to do anything more.

So, looking at my earlier post I’d modify what I stated somewhat… that invoking unpermitted functionality isn’t the issue but possibly the appearance attempting to do such. And, a common use of html encoding is to “escape” spaces which are not typically handled properly in UNIX machines without declaring the entire string as text (and possibly enclosing in quotes).