Closed Bug 19917 Opened 23 years ago Closed 22 years ago

4.xP Partial URLs of the form //hostname/path resolved wrongly.

Categories

(Core :: Networking, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: pdc, Assigned: andreas.otte)

References

()

Details

(Whiteboard: [PDT-])

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.
Summary: <b>4.xP</b>Partial URLs of the form //hostname/path resolved wrongly. → 4.xP Partial URLs of the form //hostname/path resolved wrongly.
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. ***
Blocks: 13449
Target Milestone: M15
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.
Assignee: gagan → andreas.otte
assigning this bug to me per Warrens request
Status: NEW → ASSIGNED
Target Milestone: M15 → M13
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Fixed by Andreas' changes that I just checked in.
Status: RESOLVED → REOPENED
reopened because of backout
Target Milestone: M13 → M14
This will not make it into M13
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
*** Bug 24162 has been marked as a duplicate of this bug. ***
Keywords: beta1
Putting on PDT- radar for beta1.  Won't hold beta for this bug.  Does not work 
in 4.x either.
Whiteboard: [PDT-]
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
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
verified:
NT 2000020708
Linux 2000020708
Mac 2000020708
Status: RESOLVED → VERIFIED
Looks good! Verified in 2000020708 on Win32.
You need to log in before you can comment on or make changes to this bug.