When entering an IPv6 IP in the URI field (e.g. 3eff:480:110::290), moz grabs the first part of it considers it being the hostname and the second part being the port. For a proper use with IPv6, it is at least neccessary to query it as a hostname (e.g. for use with squid - like on Netscape Navigator 4.75)

IPv6 address literals need to be quoted in square brackets ([...]) when used in a URI.

Reporter did this fix the problem?

Marking INVALID due to lack of response.

Relieving tever of IPv6 related QA.

Real problem that needs to be tested.

-> defaults

Moz's behaviour is consistent with RFC2732 "Format for Literal IPv6 Addresses in URL's". This specifies that IPv6 addresses should be enclosed in square brackets. I think this bug should be closed.

[2001:4f8:4:b:203:93ff:fec1:7c20] show done though no content, the server has an ipv4 address (www.opendarwin.org or sancho.opendarwin.org in this case) : 204.152.184.200 which mozilla is able to resolve though it does not even try it (i guess because it believe it has successfully gotten the ipv6 one ) I hope the problem is not that the server does not provide this address whith square bracket , then leading to an unfixable problem (then tell me i ll send a bug report to the proper tool) other wise this bug could be linked to: http://bugzilla.mozilla.org/show_bug.cgi?id=108108 Cheers Alban

While comment #7 is correct, there is another problem: 1. Enter an IPv6 address in the URL bar (without the square brackets: invalid). 2. Press enter. Expected results: error message Actual results: nothing happens! At least, I would expect some kind of error message (e.g. "The URL is not valid and cannot be loaded") to come up...

Pasting 3eff:480:110::290 into Mozilla 1.5 on Mac OS X 10.3.1 results in an error dialog box stating that host 3eff does not exist. This bug should be closed as INVALID.

Ignoring invalid URLs, even when using the correct IPv6 URL format the current tree (at least tbird) does not handle them correctly if the server doesn't handle IPv6 addresses. I either end up at google or some random site chosen by google's "I'm lucky" based on the address string. If the server does handle IPv6 it works fine. I think the behavior should be just like for refused IPv4 connections. Moz should bring up a dialog saying the connection is refused.

Ulrich: yes, I see this too. Looking at it now.

Comment 11 is a separate bug and should be filed separately. The original report is either INVALID or a request to have the URL parser be stricter about invalid input in the port field.

Actually, it looks like comment #11 is the same problem as comment #9. The problem is that if webshell gets a connection refused, it tries keyword fixup, but the URI fixup code doesn't know about IPv6 addresses. For Firebird, this means searching for google using the "I'm feeling lucky" button. The following patch eliminates the symptoms, as does setting the pref keyword.enable to false using about:config (not tested). I just wrote this to confirm my diagnosis: the solution is probably to make webshell smarter so it doesn't perform fixup on an IPv6 address. This should fix comment #9 and comment #11. I hope to look into this in the next few days.

Taking.

This patch fixes the problem. It looks like a reasonable way to do it. Having to include prnetdb.h into webshell is rather ugly, but on the other hand it's much better to use that than to fall over ourselves trying to parse all kinds of addresses from webshell...

Comment on attachment 139528 [details] [diff] [review] patch v1 Requesting reviews, let's see how hard the reviewers come down on it. :)

Comment on attachment 139528 [details] [diff] [review] patch v1 I'm not qualified to review this, really, and I wouldn't get to it for probably weeks given how things are going. Darin, could you take a look?

Comment on attachment 139528 [details] [diff] [review] patch v1 Looks reasonable to me r=adamlock

Comment on attachment 139528 [details] [diff] [review] patch v1 sr=darin

lorenzo: let me know if you need help landing this patch.

Darin, that would be great. I don't have CVS access...

Comment on attachment 139528 [details] [diff] [review] patch v1 marking adamlock's review.

Lorenzo, Darin wasn't cced on the bug... I've checked the patch in.

Boris: oh, I thought I had CC'd him this morning (CET, so about 12 hours ago). Thanks for checking it in!

is there anything left to do on this bug, or can it be marked fixed?

There is still a problem when numeric IP addresses are entered without square brackets. Like Mozilla in comment #9, except that Firebird tries to resolve a host, fails, and falls back to searching on google. Technically speaking this is not a bug, since IPv6 addresses in URLs should always be between square brackets. I'm sure this behaviour could be better, but I don't know how. I don't know whether this should be a separate bug or not...

Attachment 138247 [details] [diff] from bug 184433, which was checked in recently, makes sure that fixup is only performed if the DNS lookup fails. Since this never occurs for an IP address, the extra check that the attachment 139528 [details] [diff] [review] in this bug adds is not necessary any more. It should be backed out.

Comment on attachment 171935 [details] [diff] [review] back out "patch v1" sr=darin

checked in

So what is the net effect of the two checkins? Only: @@ -857,6 +860,12 @@ // if we want keywords enabled...this is just a bandaid... if (keywordsEnabled && !scheme.IsEmpty() && (scheme.Find("http") != 0)) { + keywordsEnabled = PR_FALSE; + }