Nick 'Zaf' Clifford Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)

Link local IP addresses are specific to an interface, therefore it does not make sense to specify a link-local address (eg fe80::21c:10ff:fe22:f9f) without an interface (eg eth0). 

The correct (at least I think the correct) format for specifying an interface in a URL is http://[<ipv6linklocal>%<interface>]/  eg  http://[fe80::21c:10ff:fe22:f9f%eth0]



Reproducible: Always

Steps to Reproduce:
1. Type in the URL above and press enter
2. ????
3. Profit!
Actual Results:  
Firefox says
http://[www.fe80::21c:10ff:fe22:f9f%eth0.com]/ is an invalid address (which of course it is)

Expected Results:  
The browser connects to the specified link-local IPv6 on the given interface

	Jo Hermans
	Comment 1 • 17 years ago

The best explanation I found is <http://lists.macosforge.org/pipermail/webkit-unassigned/2006-December/024077.html> . The problem is that there's no official syntax definition that allows an interface identifier in an IPv6 address.

Reported before in bug 292307, but that's now expired.

	Jo Hermans
	Comment 2 • 17 years ago

Note that Webkit (= Safari) has resolved this bug as invalid, because there's no spec that says that interface-identifiers have to be supported. And they would be of no use on the Internet either, since such an URL would probably only work from your computer .

http://bugs.webkit.org/show_bug.cgi?id=11773

Leaving this bug open until someone decides if this is worth fixing or not. My vote is for rejecting it.

	Nick 'Zaf' Clifford Reporter
	Comment 3 • 17 years ago

> And they would be of no use on the Internet either, 
> since such an URL would probably only work from your 
> computer .

I'm going to disagree with you on that. Whilst the URLs wouldn't be of any use on the big wide world Internet, on a local area network, they can be very useful. Case in point was a network device I plugged into my local network, it came up without a valid IPv4 IP address (it had its own DHCP server and thought it knew best), traditionally you'd have to change your own IP address (or add an alias) to your PC, login to the device, change it back to a sane address, etc, etc.

With v6, I found the device by doing an all nodes ping, got its v6 link-local address, and tried (and failed) to login to it with Firefox. I resorted to using the telnet interface to change its IPv4 address and configure it that way. I could have also got its global scoped address and changed it with that too I guess.

As for there being no standard, I fail to see how that should stop a feature being implemented. The commonly accepted format is <ipv6-link-local>%<interface>. 

	Christian :Biesinger (don't email me, ping me on IRC) Assignee
	Comment 4 • 17 years ago

So you tested this with Firefox 2.0.0.6 on Ubuntu? Could you make a log per the instructions at http://www.mozilla.org/projects/netlib/http/http-debugging.html and attach it to this bug?

	Nick 'Zaf' Clifford Reporter
	Comment 5 • 17 years ago

Yes.
Ubuntu Feisty
Firefox 2.0.0.6
x86 processor

I have followed the http debugging instructions, and I will attach the debug log (link-local-debug.txt), I have pruned only a few lines relating to cookies that were sent on opening to various RSS feeds.

Quick tip: to find the related lines to the problem, search for "fe80"

I tried various different input methods, but none worked.
The host in question was: fe80::208:a1ff:fe96:b473 on my eth0 interface.
eg:
$ telnet fe80::208:a1ff:fe96:b473%eth0 80
Trying fe80::208:a1ff:fe96:b473%eth0...
Connected to fe80::208:a1ff:fe96:b473%eth0.
Escape character is '^]'.
^]
telnet> quit

	Nick 'Zaf' Clifford Reporter
	Comment 6 • 17 years ago

Debug log was too large to attach without modification. so instead I have trimmed the debug log and only included the traffic related to the attempt to use the fe80: address.
I found this by searching for fe80, noting the timestamp, and trimming everything before that timestamp.
If you need the rest of the log, let me know, and I'll put it up somewhere.

	Christian :Biesinger (don't email me, ping me on IRC) Assignee
	Comment 7 • 17 years ago

Found the problem. We consider all hostnames (this includes IP addresses) containing a percent sign as invalid.

This patch makes it so that we always consider IP addresses valid.

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 17 years ago

Comment on attachment 277483 [details] [diff] [review]
patch

Makes sense. r+sr+a=bzbarsky

	Christian :Biesinger (don't email me, ping me on IRC) Assignee
	Comment 9 • 17 years ago

Checking in nsURLHelper.cpp;
/cvsroot/mozilla/netwerk/base/src/nsURLHelper.cpp,v  <--  nsURLHelper.cpp
new revision: 1.68; previous revision: 1.67
done

	Christian :Biesinger (don't email me, ping me on IRC) Assignee
	Comment 10 • 17 years ago

Comment on attachment 277483 [details] [diff] [review]
patch

this just makes us always treat IP addresses as valid hostnames, should be low risk.

	Nick 'Zaf' Clifford Reporter
	Comment 11 • 17 years ago

Just an FYI - I tried recompiling Firefox with the above patch, and from what I can tell, it didn't work. That said, I'll happily confess that it was my first time compiling Firefox, and I'm not 100% that the package I compiled is the one I'm running. 

So if you're 100% sure that the patch has fixed it, fine, but if you are working on the assumption that the patch has fixed the problem, then maybe hold-fire before closing this report, until I can recompile the entire package again, this time ensuring that I'm running the patched version.

	Christian :Biesinger (don't email me, ping me on IRC) Assignee
	Comment 12 • 17 years ago

Well, I did test the patch and it worked for me. If it's not fixed for you though, there may be an additional problem. You could wait until tomorrow and try a nightly build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.0a8pre.en-US.linux-i686.tar.bz2

(what's currently there doesn't have the patch yet, so wait 24h or so)

	Christian :Biesinger (don't email me, ping me on IRC) Assignee
	Comment 13 • 17 years ago

Nick, did you get a chance to test this in a nightly build yet?

	Daniel Veditz [:dveditz]
	Comment 14 • 17 years ago

Comment on attachment 277483 [details] [diff] [review]
patch

not approved for 1.8 branch (no trunk verification, nervous about any security implications of relaxing the '%' check for all hostnames)

	Norman Rasmussen
	Comment 15 • 17 years ago

It's not relaxing the % check, it's just saying that if it fails to parse as a hostname, but parses as an IP(4/6) address, then it's okay.

	Ralph Giles (:rillian)
	Comment 16 • 13 years ago

This patch is in mozilla-central. http://hg.mozilla.org/mozilla-central/rev/1f13e952df48

Unfortunately it looks like we've regressed; link-local ipv6 urls with device specifiers redirect to search queries for the url in Firefox 10 nightly. Perhaps clobbered by bug 504014.

	Kerry Lynn
	Comment 17 • 13 years ago

The regression occurred some time ago.  IPv6 link-local URLs are broken in Firefox 7.0.1.  When Internet Keyword Search is disabled (see http://support.mozilla.com/en-US/kb/Location%20bar%20search) and a link-local URL with a device specifier is entered, an Alert "The URL is not valid and cannot be loaded." appears.  Please REOPEN this bug.

	j.j.
	Comment 19 • 13 years ago

Reverting "Target Milestone" to avoid confusion.

> Please REOPEN this bug
No, we have bug 700999 now

	Ralph Giles (:rillian)
	Comment 20 • 13 years ago

Ok, bug 700999 was marked a duplicate of this one. reopening.

FWIW, the regressing change seems to have been security bug 504014. The commit message is "Enforce RFC 3986 syntax for IPv6 literals" and indeed RFC 3986 disallows interface specifiers. The validator can certainly be amended, but I guess we'd need policy approval from someone involved with whatever caused us to choose RFC 3986 syntax.

	Ralph Giles (:rillian)
	Comment 21 • 13 years ago

or...not. sigh.