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




17 years ago
17 years ago


(Reporter: waterson, Assigned: darin.moz)




Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
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

17 years ago
Created attachment 66312 [details]
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

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

Comment 3

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

Comment 4

17 years ago
darin, there was some talk about removing a nsStdEscape in a bug I can't find at
the moment, did that happen ?
...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

Comment 6

17 years ago
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) ...


17 years ago
Keywords: regression

Comment 7

17 years ago
':' 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

17 years ago
andreas: nope... that patch hasn't landed yet.

-> me
Assignee: neeti → darin
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

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

Comment 11

17 years ago
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

17 years ago
mass futuring of untargeted bugs
Target Milestone: --- → Future

Comment 13

17 years ago
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>?
Summary: colon (`:') character no longer allowed in <img src="..."> → URL: colon (`:') character no longer allowed in <img src="...">

Comment 14

17 years ago
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.


17 years ago
Blocks: 143469


17 years ago
No longer blocks: 143469

Comment 15

17 years ago

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)?
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 16

17 years ago
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.
You need to log in before you can comment on or make changes to this bug.