Closed Bug 19917 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: pdc, Assigned: andreas.otte)

References

(
URL
)

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: 25 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
URL: http://www.mwave.com
this one is fixed now
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 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.