Closed
Bug 121655
Opened 23 years ago
Closed 22 years ago
URL: colon (`:') character no longer allowed in <img src="...">
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
VERIFIED
INVALID
Future
People
(Reporter: waterson, Assigned: darin.moz)
Details
(Keywords: regression)
Attachments
(1 file)
292 bytes,
text/plain
|
Details |
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.
Reporter | ||
Comment 1•23 years ago
|
||
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.
Reporter | ||
Comment 2•23 years ago
|
||
Possibly related to recent URL parser changes for RDF? (Bug 120617.)
Comment 3•23 years ago
|
||
The : needs to be escaped otherwise resolving the url leads to an absolute URL with the scheme mozilla ...
Comment 4•23 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 invalid".
Comment 6•23 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) ...
Reporter | ||
Updated•23 years ago
|
Keywords: regression
Assignee | ||
Comment 7•23 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.
Assignee | ||
Comment 8•23 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?
Assignee | ||
Comment 10•23 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•23 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 13•22 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•22 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.
Comment 15•22 years ago
|
||
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
Closed: 22 years ago
Resolution: --- → INVALID
Comment 16•22 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.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•