NET_MakeAbsoluteURL is broken: it decides relative vs. absolute based on a fixed set of known URL schemes, but it should just look at the syntax. http://cvs-mirror.mozilla.org/webtools/lxr/ident?i=NET_MakeAbsoluteURL For example it parses g:h as a relative address, but it's absolute. That's the 1st test case in Roy's suite: http://www.ics.uci.edu/~fielding/url/test1.html The URI syntax spec is now an IETF draft standard: http://www.ics.uci.edu/~fielding/url/rfc2396.txt For an implementation, see HTParse.c in libwww http://dev.w3.org/cgi-bin/cvsweb/libwww/Library/src/HTParse.c?rev=2.79 Also, I see that on the Win and Mac platforms, the user can add new URL schemes to their desktop (using the registry on Win and some corresponding magic on Mac) but Unix folks are SOL. http://cvs-mirror.mozilla.org/webtools/lxr/ident?i=NET_AddExternalURLType It's traditional (i.e. in libwww and lynx since '91 I think) to allow folks to add their own URI schemes by setting foo_proxy = http://www.w3.org/foo-proxy.cgi (I personally want to add irc: and phone: to my desktop)

Actually in the new world order, NET_MakeAbsoluteURL isn't called at all. Its now handled by NS_MakeAbsoluteURL which will soon be changing to be protocol specific. Hopefully that will make things easier for all. Thanks Dan for pointing out the great links that will definitely help us test this!

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

Raising to P1, as this is arguably a test blocker. In particular, links can't be followed on a number of web sites.

Raising to P1, as this is arguably a test blocker. In particular, links can't be followed on a number of web sites.

Setting all current Open Critical and Major to M3

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

N2 merge will fix it I trust. So are we going to fix this on the tip too. M3 or not ?

Fixed with N2.

removed myself from cc

wtf? First I get "thanks for the detailed report and links to test info" and then it's promoted to P1 major... I was actually starting to hope that something might happen. And now it's been put in the someday pile? I feel quite disappointed and mislead. Is there something I can do to help get this bug fixed? I found the bug in the old code, but I was told that was old code and it's obsolte. Would somebody show me where the new code is so I can try to fix it?

Marking for M6. The new implementation I wrote works just fine. But it doesn't go in until the new netlib does.

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

Moving to M9, Necko landing in M8

Pushed past necko landing...

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Please check with Necko. There is a test case for testing url parsing now in the necko world. Its called urltest. And it also has an option to test making absolute URL from relative ones. I know some of the cases are broken (;param ones) and will fix it soon.

connolly, do you want to verify that this is fixed?

connolly, are you around? The new code is available if you would like to test it out.

I verified that URI parsing (e.g. irc://irc.w3.org/test) works in ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32.zip of Wed Aug 11 13:58:00 1999 build ID 1998081108 I haven't tested the ability of users to add their own URI scheme handlers. I wish the URI parsing interface were separate from the NS_OpenURL code, but that's just style. http://lxr.mozilla.org/seamonkey/source/network/public/nsIURL.h#35

thanks

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

What ever became of the code to allow users to register URI schemes? This functionality would probably make some people happy on bug 33282, bug 39714, and bug 44317.

+makingtest mailto and telnet are still misbehaving, I need to look at this more.