User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060508 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060508 Firefox/126.96.36.199 Sourceforge has (by mistake, I'd imagine) the following line in their page headers: <link rel="shortcut icon" href="http:///images/favicon.ico" type="image/x-icon" /> Firefox interprets this as path "/favicon.ico" on host "images". According to RFC 3986, the authority (i.e., host for HTTP urls) ends at the first "/" following the "//" after the scheme and ":", and is therefore in this case empty. Processing from there, "images" is part of the path, so I think that Firefox's interpreting it as a hostname is a bug. Reproducible: Always
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
A quick search did not find why it's working like this, so moving to Networking. var ios = Components.classes["@mozilla.org/network/io-service;1"] .getService(Components.interfaces.nsIIOService); var uri = ios.newURI("http:///images/favico.ico", null, null); uri.host >>> "images"
Component: General → Networking
QA Contact: general → networking
The "http" scheme URI registration does not allow an empty authority section. See RFC 2616 section 3.2.2. Therefore the URI in question is invalid, and the only question is what the UA should do with it; the behavior is not defined by the RFCs in question. The options are basically to not dereference the URI or to attempt to fix it up somehow. Gecko does the latter; the rules it uses are more or less summarized at http://hg.mozilla.org/mozilla-central/file/83c887dff0da/netwerk/base/public/nsIStandardURL.idl#l64 Testing with data:text/html,<iframe src="http:///google.com"></iframe> it looks like: 1) Safari fixes up the URI as "http://localhost/google.com". 2) Opera fixes up the URI as "http://0.0.0.0/google.com". 3) Chrome does the same thing as Gecko. 4) IE8 gives an "address is not valid" error; not clear what address it tried to look up, if any. Also blows away the parent document with the error page... It's not clear to me that any of behaviors 1,2,4 are particularly better than the Gecko and Chrome behavior.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.