You're holding it wrong.  Use http://[::1]/.  Because ports are also separated by colons, http://::1:80/ could either mean port 80 on ::1, or default port on ::1:80.  The braces are needed to disambiguate.

Ah, cool, thanks.  I was wondering if it was something like that.  Maybe a "Did you mean..." box would be nice if the address doesn't resolve and looks like it could've been a numberic IPv6 address without brackets?

I'll defer to the omnibox team on whether they want to do that

I'm not totally sure why comment 2 mentions :80.  It seems like the issue here is simply whether http://::1/ should be a navigation or a search.  An underlying question there is whether ::1 should be a navigation or a search.  Probably both of these boil down to whether fixup should convert a bare ::1 to [::1].

I'm not familiar enough with IPv6 syntax to answer these questions.  I think Brett added bare-bones fixup/support for IPv6 long ago.  CCing him.

I was explaining why the braces are needed in IPv6 addresses in URLs, with an example.  For instance, we could fixup http://::1:8080/ to either http://[::1]:8080/, or http://[::1:8080]/, both of which are valid IPv6 IPs.

*Valid IPv6 URLs, rather

Yeah, that makes sense, but in the absence of ambiguity around ports, perhaps we can just infer the brackets.

(Though I suspect if we do this, fixup may begin having a preference in the cases you describe.  And maybe it should?  Is one of those two meanings more common?  I'd think ::1:8080 usually means [::1:8080]?

I think [::1]:8080 would be much more common, actually, though I'm not terribly familiar with the IPv6 space.  ::1 is sufficiently magical that I'd think it's a very strong signal.

I'm not arguing we shouldn't do any automatic correction in the case of ambiguity, just pointing out there is ambiguity.

I think this is a reasonable request with a clear action: make http://::1 be fixed up to http://[::1]/, and the generalization of that (put square brackets []s around the narrowest thing).  This will allow the fixed up URL to be suggested and sometimes be default.

Probably not particularly important until IPv6 becomes more common.  Reassess then?

I'd agree that this is low priority.

 Issue 738127  has been merged into this issue.

(Note the bug I duped is a slightly different input example, but same underlying issue.)

The NextAction date has arrived: 2018-01-09

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

IPv6 still not common enough to be worth doing.  Reassess next year.

The NextAction date has arrived: 2019-01-08