647709 - IPv6 URL with embedded hex ASCII codes not correctly decoded

Status: UNCONFIRMED

(Firefox :: General, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

If I embed an IPv6 URL within an HTML link using ASCII hexadecimal representation for the [, ] and : characters then whilst the link shown at the bottom of the page suggests the browser will follow the link correctly once I actually click on the link it fails to use the correct host. It reports a server not found error. If I enter the URL directly then the browser opens the page.




Reproducible: Always

Steps to Reproduce:
1. Browse to the above link
2. Click on the Port Scanner link
3.
Actual Results:  
Server not found.

Expected Results:  
Should have decode the URL as:

http://[2a01:348:6:4be::2]/ipv6tcptest/index.php


To follow the link you need to have a globally unqiue IPv6 address, however I'm sure you can build a suitable example.

My mediawiki entry which causes the problem is:

[http://%5B2a01%3A348%3A6%3A4be%3A%3A2%5D/ipv6tcptest/index.php Port Scanner] 

I can provide additional info if required - would be useful to get it fixed before IPv6 day!

Comment 1

[[e-mail]]

Same link works correctly with Google Chrome and Apple Safari.

Comment 2

[Masatoshi Kimura [:emk]]

It doesn't work with IE9 either.
IIRC, "[" and ":" should not be percent encoded in the IP-literal production because those characters are in the "reserved" set.

Comment 3

[[e-mail]]

RFC3986 certainly defines "[", "]" and ":" in the gen-delims set of reserved characters. In section 2.4 it states

   When a URI is dereferenced, the components and subcomponents
   significant to the scheme-specific dereferencing process (if any)
   must be parsed and separated before the percent-encoded octets within
   those components can be safely decoded, as otherwise the data may be
   mistaken for component delimiters.

*If* I interpret this correctly then since all the %encoding is within the same component (the hier-part, ultimately the authority) then this would be ok, since parsing/separation would occur using the normal "//" and "/" delimiters at which point the %decoding can be applied to the resulting components which would result in the authority being the required IP-literal?

Comment 4

[Tim (fmdeveloper)]

Reporter -> Are you still experiencing this issue with the latest version of Firefox 5? Does the issue occur with the latest nightly? http://nightly.mozilla.org/

Don't have an IPv6 address to test....

Comment 5

[[e-mail]]

Hi, yes it still fails with Firefox5 (now running on Win7). I've added an example page under the following URL which you can use to demonstrate the issue:

http://ipv6.chappell-family.com/test.html

I'll try the nightly build later today.

Comment 6

[Masatoshi Kimura [:emk]]

Percent-encoding IPv6 addresses should not be allowed because the "pct-encoded" production does not appear in the "IPv6address" production.

Comment 7

[[e-mail]]

Firefox's handling does appear to be inconsistent though? When you hover over the link it shows the correctly decoded URL in the status bar at the bottom - however when you click on the link it resolves to a different URL?

Comment 8

[[e-mail]]

A couple of other points:

1. There seems to be further inconsistency too. The resolved URL is:

http://[2001%3a470%3a1f08%3a185c%3a%3a2]/

ie firefox has correct exchanged the % encoded [ and ] characters but has failed to replace the %3a characters for :'s

2. I forgot to mention that the URL in comment 5 will demonstrate the issue even in an IPv4 only environment - so feel free to try it even if you don't have IPv6 access.

Comment 9

[[e-mail]]

I've now verified operation with nightly build 7.0a1 (2011-06-28) and can confirm that it operates in exactly the same manner as firefox 4 and firefox 5.

Comment 10

[[e-mail]]

Same inconsistent results in Firefox 11. 

I can understand that you believe the RFC dictates that this is the desired behaviour, but why then does the "tooltip" suggest that Firefox is going to follow the expected URL whereas clicking on the link gives a different result? It seems your interpretations are inconsistent even within your own teams? 

Your interpretation is also obviously different to the developers of Google's Chrome, Opera and Apple's Safari since their browsers correctly follow the link.

Thanks,

Tim.

Comment 11

[[e-mail]]

Still present in Firefox 13.0.1

Comment 12

[[e-mail]]

Still present in Firefox 18.0.2 - please see:

http://ipv6.chappell-family.com/test.html

Comment 13

[clogged.drainpipe]

As of FF42b1 this bug is still present.