Bug 11773 - IPv6 addresses with interface don't do anything when clicked
Summary: IPv6 addresses with interface don't do anything when clicked
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 419.x
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://nicholas:passwd@[fe80::205:2ff...
Keywords: InRadar
: 16932 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-07 04:27 PST by Nicholas Shanks
Modified: 2013-07-26 05:15 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Shanks 2006-12-07 04:27:27 PST
An IPv6 address as currently needed by Mac OS X requires an interface specified to work. This is done by appending %en0 for ethernet, etc. For example: http://nicholas:passwd@[fe80::205:2ff:fe0f:149e%25en0]:81/ which is my local Apache 2 installation (the % must be URL-escaped to %25). Sadly clicking on links with the interface specified does nothing, even though they are highlighted correctly. Copying and pasting the link into the address bar works just fine.
I don't know if this is a WebKit or NSURL bug, but first saw it in Colloquy.
See http://colloquy.info/project/ticket/932
Comment 1 Mark Rowe (bdash) 2006-12-11 18:04:42 PST
I've done a little digging into this case: the reason the link has no effect is that KURL::parse decides the URL is invalid due to the presence of non-IPv6 address characters inside the hostname portion of the URL (the invalid characters being "%en0").  The reason why these are considered invalid is somewhat interesting...  RFC 2732, Format for Literal IPv6 Addresses in URL's, (<http://www.faqs.org/rfcs/rfc2732.html>) changes the host portion of the URL syntax to:

      host          = hostname | IPv4address | IPv6reference
      ipv6reference = "[" IPv6address "]"

where IPv6address is defined over in RFC 2373, IP Version 6 Addressing Architecture (<http://www.faqs.org/rfcs/rfc2373.html>).  It's definition is:

      IPv6address = hexpart [ ":" IPv4address ]
      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

      IPv6prefix  = hexpart "/" 1*2DIGIT

      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
      hexseq  = hex4 *( ":" hex4)
      hex4    = 1*4HEXDIG

which is, more or less, a colon-delimited sequence of hexadecimal digits.  It makes no allowance for the scoped address format.  The scoped address format is introduced in RFC 4007, IPv6 Scoped Address Architecture (<http://www.faqs.org/rfcs/rfc4007.html>), and optionally append a percent character followed by an arbitrary zone identifier to the end of an IPv6 literal address.  Unfortunately in section 11.7 it says:

   [T]his document does not specify how the format for non-global
   addresses should be combined with the preferred format for literal
   IPv6 addresses.  In any case, it is recommended to use an FQDN
   instead of a literal IPv6 address in a URL, whenever an FQDN is
   available.

So in summary, the scoped address format appears to be totally unspecified when used in the context of a URL.

Recent builds of Firefox also appear to have issues with URLs of this format, attempting to treat them as a hostname to be resolved.  This leads to a "host not found" error being displayed, which is misleading but in many ways more useful than ignoring the mouse click like WebKit currently does.  It's not obvious whether the loader code that is used to load pages will function correctly in the presence of the scoped address, or whether this would also need addressed at other levels.
Comment 2 Alexey Proskuryakov 2007-02-18 23:26:25 PST
(In reply to comment #1)
> So in summary, the scoped address format appears to be totally unspecified when
> used in the context of a URL.

This sounds just about right: it would be very strange for an URL to depend on a local machine setup.
Comment 3 Mark Rowe (bdash) 2007-02-19 00:50:52 PST
As outlined in comment 1, the use of a scoped IPv6 address in a URL is unspecified and therefore the current behaviour is not incorrect.
Comment 4 Alexey Proskuryakov 2008-01-18 22:51:36 PST
*** Bug 16932 has been marked as a duplicate of this bug. ***
Comment 5 Deirdre Saoirse Moen 2010-09-08 18:32:02 PDT
<rdar://problem/8406834>
Comment 6 Sascha Silbe 2013-07-26 05:15:35 PDT
Use of IPv6 link-local addresses as part of a URL is now covered by RFC 6874 [1].

IPv6 link-local addresses are quite useful for interacting with embedded devices. They require neither manual configuration (like static IPv4 addresses do) nor additional equipment (like a DHCP server for giving out IPv4 addresses).


[1] http://www.rfc-editor.org/rfc/rfc6874.txt