One of the allowed forms of a partial URL is //hostname/path (in other words, only the scheme portion 'http:' has been removed). This is resolved by prefixing the partial URL with the scheme of the base URL. (This is based on my recall of RFC 1808 or RFC 2396; it may be that the more recent RFCs on relative URLs change the rules.) <p>There is a page http://intranet/index.html on our intranet server which contains a link to //penguin/foo/bar.html. In Netscape this causes a jump to http://penguin/foo/bar.html; with Mozilla this causes a jump to http://intranet//penguin/foo/bar.html, which does not exist. <p>I listed this bug as 'minor' since very few web pages are likely to use this obscure syntax, since it saves only five characters and causes trouble when moving the pages between, say, local files and the web server.

I have locally a rewritten urlparser and other changes in nsStdURL.cpp that can handle this.

*** Bug 19200 has been marked as a duplicate of this bug. ***

RFC 2396 *does* formally specify these partial URLs starting with // as <net_path> references - see bug 19200 for details. In the context of that bug, (http-equiv="refresh": there can be no ambiguity about the scheme here), at least, these partial URLs should work. This syntax may be natural linguistically for references to URLs served by MS-IIS webservers on the same LAN, since the RFC 2396 <net_path> name for the server would parallel the UNC name for the server.

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.

*** Bug 22746 has been marked as a duplicate of this bug. ***

It seems the ability to support // URLs would have a good purpose. One of which would be to keep the protocol the same. Assuming I have a copy of a document that is on http: and https: and I want them to goto a new server, but keep it either as http: or https: respective of what they are already using, a // URL would be the only logical solution.

assigning this bug to me per Warrens request

Fixed by Andreas' changes that I just checked in.

reopened because of backout

This will not make it into M13

Clearing FIXED resolution due to reopen.

*** Bug 24162 has been marked as a duplicate of this bug. ***

Putting on PDT- radar for beta1. Won't hold beta for this bug. Does not work in 4.x either.

Accually it does work in 4.x For example http://wwww.mwave.com uses this form of redirection (though they could fix it on their site) and it does not work on mozilla 5.x but it does work on 4.x

this one is fixed now

verified: NT 2000020708 Linux 2000020708 Mac 2000020708

Looks good! Verified in 2000020708 on Win32.