When Mozilla encounters a URL with a colon character ':' embedded in the filename it's unable to follow the link. In the case where an img src tag references such a file, Mozilla does not display the image. An example: <P><B><A HREF="apapane.serial1-0:0.html">apapane.lava.net (No hostname defined for IP address): Serial1/0:0 <BR>82.HCGS.515654..GTEW (AT&T)</B><P> <SMALL><!--#flastmod file="apapane.serial1-0:0.html" --></SMALL></P> <IMG BORDER=0 WIDTH=500 HEIGHT=135 SRC="apapane.serial1-0:0-day.gif"> </A> This problem has been seen on M17 and M18 builds for various Windows versions and OS/2. It may also exist on other OS.

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

over to Networking

The magic bug 6-0-0-0-0! (Might as well confirm while I'm here -- for a Linux web server (where ":" is legal in the filename/filesystem), a windows or linux mozilla client fails to load <a href="foo:bar.html">foo</a>.

Yes! I had dreamed of getting this bug (number that is) :)

<a href="foo:bar.html"> refers to the resource bar.html using the foo naming scheme. That's why ':' should be escaped as '%3A' in this case. IE and Mozilla do essentially the same thing here. I can't see it's justified hacking the code just for bug compatibility with NS4.

That's not quite the same. Suppose the URL had been <a href="http://xyz.net/foo:bar.html"> ? In this case foo:bar.html is a perfectly valid filename and foo is not being used as a naming scheme.

This is all about doing the right thing with relative URLs. The first : clearly marks the scheme in an URL (and makes it an absolute one), if you don't want that, then you have to mask the : (escape it) properly. This bug should be marked invalid.

Suppose you do continue to use absolute URLs but still have colons in the filenames? Then the bug still presents a problem for backward compatibility. How about the following pseudo-logic to handle this? When parsing for the naming scheme, you need to determine at some point whether it's a valid name. If it's not a known naming scheme, then backup and assume the colon is part of a relative filepath. If it's a known scheme, use it but if there are any subsequent colons they should be assumed to be part of the filepath.

The urlparser currently does not know if a scheme is valid or not and following the rfcs it does not need to know. When a file is accessed directly over the filesystem we can do some escaping magic, but if it is accessed over a link embedded in a html document we can expect that the writer of the document follows the rules on creating correct links. We dropped the support of an entire class of (deprecated) relative urls (bug 22251) because of this, I don't think we will make an exception here.

I agree with Andreas here... marking as wontfix

Verified WONTFIX.

+relnote - I'll sort this out w/ the other URL bugs and doc it in the next release (0.9.4?)

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

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