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.
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.
Possibly related to recent URL parser changes for RDF? (Bug 120617.)
The : needs to be escaped otherwise resolving the url leads to an absolute URL with the scheme mozilla ...
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 invalid".
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) ...
':' 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.
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?
i'm not sure what we used to do... it's surprising to me that this would have changed so recently.
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.
mass futuring of untargeted bugs
Target Milestone: --- → Future
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="...">
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.
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)?
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.