121655 - URL: colon (`:') character no longer allowed in <img src="...">

Status: VERIFIED INVALID

(Core :: Networking, defect)

Description

[Chris Waterson]

Apparently, this used to work, and recently regressed:

  <img src="mozilla:banner.gif">

where the name of the file on the hard-drive was `mozilla:banner.gif'. I can't
give out the URL of the real-world test case, because it's secret, but I can
attach a test case that demonstrates the problem.

Comment 1

[Chris Waterson]

Attachment: simple test case

Save the above test case as `test.html'. Save the Mozilla banner on your hard
drive as both `mozilla-banner.gif' and `mozilla:banner.gif'. All three images
show up on 4.7, and apparently in 0.9.6. In current builds, the last image
doesn't show up.

Comment 2

[Chris Waterson]

Possibly related to recent URL parser changes for RDF? (Bug 120617.)

Comment 3

[Andreas Otte]

The : needs to be escaped otherwise resolving the url leads to an absolute URL
with the scheme mozilla ...

Comment 4

[Andreas Otte]

darin, there was some talk about removing a nsStdEscape in a bug I can't find at
the moment, did that happen ?

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

...except that in IE5, NS4.x, Mozilla 0.9.2 and Mozilla 0.9.6 it _doesn't_ need
to be escaped.  We've regressed here, even if they URL itself is "technically
invalid".

Comment 6

[Andreas Otte]

Somewhere down the road it must have gotten escaped in 0.9.6, that part of
::Resolve (detecting absolute urls) has not changed since M9 (or near that) ...

Comment 7

[Darin Fisher]

':' is technically valid in the path of an URL, and i'm not sure it is possible
to interpret 'mozilla:banner.gif' in a disambiguous way.

what if 'mozilla' were a registered protocol?  then you would expect this to
invoke the mozilla protocol handler, right?  we could possibly fallback to
interpreting it as a relative URL if there is not a protocol registered under
the 'mozilla' scheme, but other than that i don't believe there is anything that
can be done to solve this bug.

Comment 8

[Darin Fisher]

andreas: nope... that patch hasn't landed yet.

-> me

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I think that "fallback" plan is probably for the best, and I suspect it's what
other browsers do.  What did we do back in 0.9.6?

Comment 10

[Darin Fisher]

i'm not sure what we used to do... it's surprising to me that this would have
changed so recently.

Comment 11

[Andreas Otte]

That's the whole point: I can't think of anything that changed in the parser
regarding this problem. And according to RFC2396 we don't need to look for a
registered protocol, the syntax does the trick.

Comment 12

[Darin Fisher]

mass futuring of untargeted bugs

Comment 13

[benc]

This is because anything with a ":" in this situation is treated as absolute right?

So wouldn't this affect all entrypoints for URLs, not just <IMG SRC>?

Comment 14

[Andreas Otte]

Yes, of course. And whatever happend for this to "regress" it is not located in
the urlparser I think because the principles behind ::Resolve have not changed
since M9.

Comment 15

[benc]

RESOLVED/INVALID:

If there is an about: handler that returns just an image, it will work:)

Unless I have overlooked something, RFC 2396 states that the presence of the ":"
in a relative URL makes the reference absolute.

Escape the ":" if you want it to work.

Andreas, can you VERIFY (or reopen if you disagree)?

Comment 16

[Andreas Otte]

Technically that is not 100% true anymore because as allowed by rfc2396
backwards compatibility support for deprecated relative urls like http:file or
http:/path has landed. However if the "protocol" part of the relative url is not
the same as the base url, the url is considered absolute, and we are at the same
point as before the landing.

Still open is the claim this has worked in previous versions. But that does not
change the fact that colons in the first part of urls need to be escaped if they
do not separate scheme from the rest or host from port. Verified.