60000 - colons in href and img tags not accepted

Status: VERIFIED WONTFIX

(Core :: Networking, defect, P3)

Description

[tony]

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.

Comment 1

[tony]

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

Comment 2

[Asa Dotzler [:asa]]

over to Networking

Comment 3

[John Morrison]

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>.

Comment 4

[Gagan]

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

Comment 5

[Richard Brodie]

<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.

Comment 6

[tony]

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.

Comment 7

[Andreas Otte]

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.

Comment 8

[tony]

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.

Comment 9

[Andreas Otte]

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.

Comment 10

[Gagan]

I agree with Andreas here... marking as wontfix

Comment 11

[Bradley Baetz (:bbaetz)]

Verified WONTFIX.

Comment 12

[benc]

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

Comment 13

[R.K.Aa.]

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

Comment 14

[jlarsen]

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