573701 - URL encoded IDN behaves very differently in browsers, what is the correct behaviour?

Status: UNCONFIRMED

(Firefox :: General, defect)

Description

[Kai de Leeuw]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

If an IDN URL is encoded, like the URL in the URL field of the bug, if I use Firefox, I end up on an error page genererated by the browser. It does not attempt to access the server adress at all, it seems.

In IE, the encoded characters seem to be interpreted literally in some way, and a lookup for a host is attempted. The same happens in Safari, with the difference that the characters are made in to a non escaped variant. http://%c3%a5%c3%a4%c3%b6.bugzilla.mozilla.org showcases that Safari and IE indeed accesses the server, as the catch all functionality on your servers redirects to http://bugzilla.mozilla.org.

In Opera and Chrome, I end up on the IDN domain that I would get if I would have either put the punycode _OR_ the non escaped unicode characters. So in those two browsers it doesn't matter if you put the host encoded or not.

Reproducible: Always

Steps to Reproduce:
1. Click the link in different browsers
2. Behold as there are three different outcomes depending which browser you use

Actual Results:  
Three different ways of handling encoded IDNs

Expected Results:  
One way of handling encoded IDNs