There seems to be some confusion. What I suggest is to support more clickable 
URL's. The behaviour in Mozilla, IE (and probably Opera, too), if you insert 
the above URL (use the text, not the actual link, since this is generated by 
bugzilla) is that if you insert it into the location bar, the whitespace is 
replaced by %20 immediately. If you copy a link containing a whitespace, it is 
also replaced by %20 (see testcase on http://www.timohummel.com/kde-
bugs/testcase-53751).

Hmm, no idea how to sovle that. 

I fail to see the problem actually... links with spaces in them can be copied to the 
location bar just fine and they will work just fine. (CVS HEAD) 

Probably I failed to explain it correctly. Remember that Konqueror handles such
URL's correctly, but it is a "usability problem". Actually I don't know what the
current behaviour is, but this bug is based on Konqueror which came with KDE 3.0.x.

Assume you have got the following URL (imagine <SPACE> as regular space as typed
on the keyboard):

http://www.foo.bar/test<SPACE>image.png

With that URL, we have a few problems:

- Copying that URL out of the location bar to another application usually breaks
the link since the <SPACE> is handled as URL end.
- Some web servers expect an URL-encoded (i.e. %20) space instead of a plain space.
- Plain spaces within URL's are considered unsafe as of RFC 1738
(ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt).

How other browsers handle this:
- If an URL contains a space, it will be transparently replaced with their
urlencoded counterparts (e.g. http://www.foo.bar/test<SPACE>image.png will
placed as http://www.foo.bar/test%20image.png in the clipboard).

If you look at the original bug report, you'll notice the URL:
http://www.monday-rec.com/party/2002-09-07 Studio/ 

"Studio/" belongs to the original URL, but isn't handled as such since the space
breaks it. The Link as inserted using Konqueror. With Mozilla, it would have
looked like that:
http://www.monday-rec.com/party/2002-09-07%20Studio/ 

Mozilla replaced the space with %20 when I copied it to the clipboard. 

Ah, ok. Yes, "Copy Link Location" uses KURLDrag which puts KURL::prettyURL() in 
the clipboard which does not encode spaces. We could perhaps use KURL::url() 
instead. 
 
Relevant code is in kdecore/kurldrag.cpp 

Hmm... there's a problem with url/prettyURL with regard to IDN domains: the copied URL will contain the 
encoded name which should not be shown to the user. However, we have no way of knowing whether 
the target program supports IDN or not. More so, we don't know whether the user wants to see the 
encoded name or not. 
 
In my opinion, the encoded name should never be copied to the clipboard. 
 
However, I agree with the poster regarding the handling of whitespaces copied into the clipboard. I 
have yet to see a program that will understand an URL as it is, so whitespaces should be converted to %
20. 
 
I might also point out that KURL handles the whitespaces correctly. They are converted to and from %20 
as needed: the "pretty" URL that is shown in the Konqueror location bar uses whitespaces, whereas the 
internal data is %-encoded. 

I don't agree with that. Fact is that if there are non-encoded URL's in the
clipboard, many applications will fail. Why don't we handle the problem as every
other application does (see Mozilla and IE, not sure about Opera) and copy an
encoded URL to the clipboard? I know, it doesn't look nice, but IT WORKS.

Agreed that it works. I am only concerned about IDN domains showing up wrong where 
they shouldn't. For instance, imagine you're copy-pasting a domain into this bug report or 
to an e-mail. The data has to be preprocessed and changed back into the proper Unicode 
form. I.e., it would no longer be simple text. 
 
Or, then again, a special exception should be opened to whitespaces. Everything else 
would be the "pretty" form. 
 
Any thoughts? 

I am still talking about pure ASCII-encoded URL's which will definitely work on
every platform, and every application. No unicode magic.

Example URL:
http://www.timohummel.com/party/2002-03-22%20Spexx%20Krefeld/

Other characters shouldn't be in the URL anyways, as specified by RFC 1738 (is
there a revised version of that RFC?).

Btw, what is an "IDN" domain? Sorry to be clueless at this point.

The following URL contains an IDN: 
	http://www.multim

I suggest helping the user by:
  1. Giving a visual clue in the location bar (background color --tricky--, warning icon, font ?) all cases where prettyURL is different from fully encoded URL and could cause problems (e.g with cut-and-paste into konsole).
  2. Adding an action (and keyboard shortcut) to switch between prettyUTL and fully encoded name.

This way, having prettyURL as the default would be perfectly acceptable, since there would be a way around its limitations.
An option for the default (prettyURL or fully encoded URL) may also be added.

Example: in the case of IRI-containing URL:
- The user sees http://www.domain.com/r�um�pdf AND a graphical clue that this is not encoding-safe as plain text.
- The user wants to cut-and-paste the URL to an application (e.g wget). He knows (graphical clue) that this would cause problem. 
- He then switches to fully encoded URL, then sees http://www.domain.com/r%C2%A9sum%C2%A9.pdf in the location bar, together with a graphical clue that this is encoding safe.
- He can then cut-and-paste the correct URL into what he wants.

Does this make sense ?

*** Bug 69101 has been marked as a duplicate of this bug. ***

*** Bug 63440 has been marked as a duplicate of this bug. ***

I've place a couple of patches against 3.4.0-rc1, which hardcode the changes to provide escaped URIs in both the location bar and RMB popup menu, over in http://bugs.kde.org/show_bug.cgi?id=88353 in case anyone's interested.

I'm not a coder by trade, so although they work for me, I'm sure they could be done better.

It would be nice for it to be a toggle-able option...

*** Bug 88353 has been marked as a duplicate of this bug. ***

Still no solution?

Actually Qt4's QUrl, which KDE4's KUrl is based on, doesn't decode %20 into ' ', so this bug will be fixed with KDE4.
Konqueror's location bar uses pathOrUrl now, so that spaces in local paths will appear as spaces,
but spaces in HTTP urls will appear as %20.

I'm glad that this will be fixed with Qt4, a nasty bug which has been around for three years now.